# Deploying WordPress with Capistrano screencast **URL:** https://discourse.roots.io/t/deploying-wordpress-with-capistrano-screencast/863 **Category:** bedrock **Tags:** deploys **Created:** 2013-12-10T15:54:36Z **Posts:** 69 ## Post 1 by @swalkinshaw — 2013-12-10T15:54:37Z I figured it would be useful to have a thread dedicated to this screencast but more important just deploying with Capistrano in general (especially since there was no accompanying blog post). Screencast here: [Deploying WordPress with Capistrano Screencast | Roots | Roots](http://roots.io/screencasts/deploying-wordpress-with-capistrano/) I went through a lot of files in the screencast and now they are available in a Gist: [Files from http://roots.io/screencasts/deploying-wordpress-with-capistrano/ · GitHub](https://gist.github.com/swalkinshaw/7892821) --- ## Post 2 by @Jaace — 2013-12-10T19:49:54Z Thanks for that screencast – I’ve been looking to use Capistrano for awhile now and this is a good starting point. I am a little confused about putting npm and grunt on the staging/production server since the JS would probably be compiled at that point? I guess there is more to Grunt than just that but I have it being ignored for my .git repo and it seems to be more of a “development only” tool for me. What are some good reasons for putting it on your staging or production environment? I found an older piece of code last time I was trying Capistrano with Wordpress attempting to migrate the database for WordPress deployment via Capistrano. I was never able to get it to work. ([https://github.com/nathanielks/Wordpress-Capistrano-Deploy/blob/master/config/deploy/staging.rb](https://github.com/nathanielks/Wordpress-Capistrano-Deploy/blob/master/config/deploy/staging.rb)) Do you see anything broken about this code? I’m going to take another look after I’ve wrapped my head around Capistrano a bit more and go through the sceencast again. Is this something you’d recommend doing for a deployment or is this better left to a manual workflow? I can see in certain cases how I wouldn’t want to upload the database to a staging server and most likely never to a production environment but it may be useful sometimes, like for the initial deployment. This was another interesting article with some helpful tips when I was searching about using Capistrano before this screencast. It’s from 2011 so I don’t know how much things have changed since then for this workflow. ([http://theme.fm/2011/08/tutorial-deploying-wordpress-with-capistrano-2082/](http://theme.fm/2011/08/tutorial-deploying-wordpress-with-capistrano-2082/)) --- ## Post 3 by @treb0r — 2013-12-10T20:35:09Z Hi Scott, Just finished watching the screencast. There’s a lot to go at here but it all makes sense. One thing that you didn’t touch on is MySQL: I’m wondering about best practice for moving databases from dev to stage to production and then back to dev again? I want to manage Wordpress entirely using composer, that is, I don’t want anyone using the standard Wordpress mechanisms for installing and updating plugins and themes. I also want to test Wordpress core upgrades on the staging server before deploying to production. I’m wondering how I can handle this given that plugin and core upgrades can modify the database. Also, is it posible to associate a specfic capistrano release with a specific named MySQL database so i can rollback the DB too? I’m also wondering if it would make sense to add another stage for development, and then define a task that dumps out a copy of the production database, runs a sed command to find and replace the hostname and then updates the MySQL database on my development VM. I could also use a .maintenance file to temporarily disable the production site while I’m working and prevent anybody from modifying anything. Obviously I will need to add tasks for the other stages to handle the databases, but that’s fine. How do you guys handle MySQL for [roots.io](http://roots.io)? Do you store dump files in git? Also, not sure if it’s just my copy, but the screencast comes to an abrupt end mid sentence! Thanks for everything! --- ## Post 4 by @swalkinshaw — 2013-12-10T21:16:28Z Sorry, I can see how that would be confusing. Basically we use Grunt slightly differently on our `roots.io` site than the Roots theme by default does. Roots theme would need the JS compiled already so you’re correct that you wouldn’t need to run Grunt during the deploy. I mostly wanted to show how to use Capistrano’s hook and deploy workflow so Composer and Grunt were good examples. The way Roots theme does it right now isn’t completely ideal since you need to modify your `scripts.php` file and commit it. We get around that on `roots.io` by not using WP’s enqueue functionality. Obviously we didn’t want to make that the default option. There’s a lot of code in that example but I don’t see anything immediately wrong with it. I’d recommend writing/using a Capistrano task for DB migration/syncing but probably not as part of the default deploy flow. It could be a manual task you run whenever you want it. You have to be really careful about overwriting databases if you’re doing it everytime. Quick glance at that last article and the general concepts apply but all the code is quite different now. --- ## Post 5 by @swalkinshaw — 2013-12-10T21:26:01Z First, sorry about that abrupt end. I actually wasn’t aware of that. There’s also a small audio glitch I found out about as well :(. Unfortunately I overwrote my main project file for the screencast and can’t fix those issues. I almost thought I lost everything at one point but realized I had rendered out a full version thankfully. Maintenance: wanted to quickly mention there’s an official plugin for that: [https://github.com/capistrano/maintenance](https://github.com/capistrano/maintenance) DB syncing: This is a giant topic that there’s no correct answer to. It seems to be the one thing everyone asks about most and unfortunately it’s such a big topic that I couldn’t get to it in the screencast. The release specific named db is an interesting idea… Off the top of my head you could hook into the deploy flow. Maybe `after 'deploy:updated'` and copy the database to a new one with the release timestamp. Basically, you could duplicate how Capistrano works with its `releases` directory but for databases. It would definitely take some work but it could be very flexible. You could easily rollback to any one. At a minimum maybe you’d just have a backup and current db. Your other idea about a development stage and replacing the hostname sounds fine as well. This is why it’s a difficult topic since there’s tons of solutions. For `roots.io` we actually use [https://github.com/scottgonzalez/grunt-wordpress](https://github.com/scottgonzalez/grunt-wordpress) so all our content is actually static content files. We do however keep some sql files in Git because we need to sync users which isn’t handled by `grunt-wordpress`. It’s not ideal but it works. Since we don’t often need to sync the database (thanks to using static content files), we just do it manually when we need to. --- ## Post 6 by @treb0r — 2013-12-10T21:33:21Z Thanks Scott. At least now I know that I’m not completely crazy. I like the idea of keeping a separate database for every release, up to a mximum of say 5, the Capistrano default. Most of the sites I’m working with these days are small so there’s no issue there. I can see why you keep your content in static files, makes things much more straightforward. Unfortunately it’s not an option for me as most of the sites I’m working with are for non technical clients who like using Wordpress as a CMS. Thanks again :wink: --- ## Post 7 by @swalkinshaw — 2013-12-10T21:39:22Z Wait, I think you might be. I just took your word for it but I checked now and the video ends as it should. Should be 52:24 long. Last thing I talk about is getting help on the forum. So just make sure the entire thing downloaded. --- ## Post 8 by @treb0r — 2013-12-10T21:41:38Z Duh, just checked my firefox download screen and it says the download failed. I only missed a couple of seconds though so no worries. Sorry about the false alarm! --- ## Post 9 by @mAAdhaTTah — 2013-12-11T16:04:17Z I bought the screencast - really helpful, thanks! I had been paying for Beanstalk to manage my deployments, but since I’m not working with a team, I was looking into switching to Capistrano, so your screencast came along at just the right time! I did have one question: are you supposed to commit your Capistrano-related files to your Git repository or exclude them? I know Composer/Grunt/etc. are supposed to be committed because they’re deployed, but since the Cap files are really only used by the machine doing the deployment, is it necessary? --- ## Post 10 by @swalkinshaw — 2013-12-11T17:40:34Z Yes! 100% they should be committed. That is part of your project and it’s especially important if you’re working with anyone else who’s also deploying. I guess you could make the argument that they shouldn’t be on your production server, but it doesn’t really matter. You could always exclude them. --- ## Post 11 by @mAAdhaTTah — 2013-12-11T22:21:12Z Thanks - by exclude, you mean exclude from deployment? How would I go about that? --- ## Post 12 by @swalkinshaw — 2013-12-11T22:38:07Z I did mean that. Capistrano uses `git archive` now so you can actually ignore files by setting up a `.gitattributes` file. See [https://github.com/capistrano/capistrano/pull/626](https://github.com/capistrano/capistrano/pull/626) The more files you ignore the faster your deploy will be as well. --- ## Post 13 by @Jaace — 2013-12-12T16:18:07Z Hi Scott, This may be beyond the scope of what you can help with but I’m scratching my head over here and thought I’d ask in case: I’ve got my files all set up, deploy key on Bitbucket for my hosting, connection set via SSH but I’m getting this error every time I run bundle exec cap staging deploy, I x’d out my IP for privacy below. Not sure where to start with this error, any ideas? `testing git:(master) bundle exec cap staging deploy [deprecated] I18n.enforce_available_locales will default to true in the future. If you really want to skip validation of your locale you can set I18n.enforce_available_locales = false to avoid this message. INFO [f15313b9] Running /usr/bin/env mkdir -p /tmp/testing/ on xxx.xxx.xxx.xxx DEBUG [f15313b9] Command: /usr/bin/env mkdir -p /tmp/testing/ INFO [f15313b9] Finished in 1.551 seconds with exit status 0 (successful). DEBUG Uploading /tmp/testing/git-ssh.sh 0.0% INFO Uploading /tmp/testing/git-ssh.sh 100.0% INFO [5bda3160] Running /usr/bin/env chmod +x /tmp/testing/git-ssh.sh on xxx.xxx.xxx.xxx DEBUG [5bda3160] Command: /usr/bin/env chmod +x /tmp/testing/git-ssh.sh INFO [5bda3160] Finished in 0.405 seconds with exit status 0 (successful). DEBUG [2a8dbb50] Running /usr/bin/env git ls-remote git@bitbucket.com:Jaace/testing.git on xxx.xxx.xxx.xxx DEBUG [2a8dbb50] Command: ( GIT_ASKPASS=/bin/echo GIT_SSH=/tmp/testing/git-ssh.sh /usr/bin/env git ls-remote git@bitbucket.com:Jaace/testing.git ) DEBUG [2a8dbb50] fatal: cannot exec '/tmp/testing/git-ssh.sh': Permission denied DEBUG [2a8dbb50] fatal: unable to fork DEBUG [2a8dbb50] Finished in 1.499 seconds with exit status 128 (failed).` --- ## Post 14 by @swalkinshaw — 2013-12-12T16:23:58Z Looks like your `/tmp` partition is set to `noexec`. See this question for details: [http://community.webfaction.com/questions/15144/capistrano-3-deploys-fatal-error-executing-tmpmyappgit-sshsh](http://community.webfaction.com/questions/15144/capistrano-3-deploys-fatal-error-executing-tmpmyappgit-sshsh) If that’s your own server you should be able to edit `/etc/fstab` and remove `noexec`. If it’s not your own you may not be able to change it so follow the workaround in the link above. --- ## Post 15 by @Jaace — 2013-12-12T16:27:51Z Thanks! It’s not my own server; it’s a shared hosting server so I had a feeling this was going to be a bit more difficult. Thanks for the link! --- ## Post 16 by @Jaace — 2013-12-12T16:54:51Z Just one more quick question – when the deploy command is referring to making the tmp directory (or whatever you choose to use instead, I chose “foobar” just to test it out), that’s getting created on the server you’re deploying to, right? I’m just totally confused by the next few errors I get which is saying it’s uploading ~/foobar/testing/git-ssh.sh and it’s failing… not sure why it would be uploading that directory or if it’s uploading TO that directory. `➜ testing git:(master) ✗ bundle exec cap staging deploy [deprecated] I18n.enforce_available_locales will default to true in the future. If you really want to skip validation of your locale you can set I18n.enforce_available_locales = false to avoid this message. INFO [bbc85d0d] Running /usr/bin/env mkdir -p ~/foobar/testing/ on xxx.xxx.xxx.xxx DEBUG [bbc85d0d] Command: /usr/bin/env mkdir -p ~/foobar/testing/ INFO [bbc85d0d] Finished in 1.794 seconds with exit status 0 (successful). DEBUG Uploading ~/foobar/testing/git-ssh.sh 0.0% cap aborted! scp: ~/foobar/testing/git-ssh.sh: No such file or directory` I checked and that “foobar” directory is getting created on my server too with rwx for my user… so strange. --- ## Post 17 by @swalkinshaw — 2013-12-12T17:12:10Z That’s correct. Every command that Capistrano runs is happening on the (remote) server you’re deploying to including the tmp directory. It’s a little difficult to tell but it seems like whatever solution you did to change the tmp directory might not be entirely correct. One thing to try since you’ve changed some settings is to completely delete the `deploy_to` folder (`~/foorbar` and the `tmp` dir as well) on the remote server which will make Capistrano basically start from scratch. Note: it looks like you should just be able to do `set :tmp_dir, "~/tmp"` in `deploy.rb` to get a tmp dir in your home directory. --- ## Post 18 by @Jaace — 2013-12-12T17:18:20Z Thanks Scott – I tried setting the :tmp\_dir like you mention already in deploy.rb and just erased the folder where it deploys to, but still the error is happening. It’s saying it fails when it uploads the [git-ssh.sh](http://git-ssh.sh) file and that the file or directory doesn’t exist. I’ve verified that the directory does exist and that my testing directory gets created in that specified directory. It’s like it’s only having trouble with this [git-ssh.sh](http://git-ssh.sh) file but I’m not even sure what that is. This fails much earlier than when I don’t use the :tmp\_dir directive in the deploy.rb file though. Thanks for taking the time to help – I’m going to search around on Google more and try to figure out what’s happening. --- ## Post 19 by @Jaace — 2013-12-12T17:31:16Z I got a bit further this time – up to creating the symlink for the media folder. The reason why it wasn’t getting passed the [git-ssh.sh](http://git-ssh.sh) upload for me before is that I needed to actually spell out the path instead of using ~, so: set :tmp\_dir “~/tmp” is now set :tmp\_dir, “/home3/jaace/tmp” and that works fine up to the next error. Hope that helps anyone else using a shared hosting solution like myself. --- ## Post 20 by @swalkinshaw — 2013-12-12T17:38:50Z Good debugging! This is the explanation behind that: [https://github.com/capistrano/capistrano/issues/734#issuecomment-27285227](https://github.com/capistrano/capistrano/issues/734#issuecomment-27285227) --- ## Post 21 by @Jaace — 2013-12-12T18:56:42Z Another question - I’ve had my media folder within the wp directory (I think based off of the Composer screencast) but would you recommend moving that media folder to the root level since it’s linked now or can it stay in the wp directory? I think I remember something about how it has to be within the wp directory but I can’t recall specifically. --- ## Post 22 by @swalkinshaw — 2013-12-12T19:11:12Z I honestly forget what I said in that screencast but I really hope I didn’t recommend keeping the `media` folder in the `wp` directory. Nothing should touch that directory since it’s a dependency managed by Composer. Here’s an mu-plugin we use to set some options including the uploads dir: [https://gist.github.com/swalkinshaw/6400708](https://gist.github.com/swalkinshaw/6400708) --- ## Post 23 by @Jaace — 2013-12-12T20:04:46Z Thanks for this! Another note – I had to change the document root for my directory that’s getting the deploys to use “/current” instead of just the root level since it is sym linking the latest release to “current”. --- ## Post 24 by @swalkinshaw — 2013-12-12T20:13:31Z Yep, Apache or Nginx needs to point to /current as the document root when using Capistrano. Good point that was a bit beyond the scope of the screencast. At some point I may do a brief blog post about basic server changes needed for Capistrano deploys. --- ## Post 25 by @Jaace — 2013-12-16T16:03:11Z I’ve gotten pretty far with deployments but I still cannot get composer to run through Capistrano on my shared hosting server for some reason. I’ve set up Composer on my hosting and aliased it through .bash\_profile so it can run with just the “composer” command properly, which is what Capistrano Composer seem to be using. I’ve also been able to just cd to my latest release directory and run `composer install` with no problems, so maybe that’s what I’ll end up doing if I can’t get this to work. I get the following when Capistrano tries to run composer – any idea what could be going on here? My initial thought is that it can’t use my alias I set up in my .bash\_profile but I don’t know where I can even change the command that’s run for Capistrano to be the full path. I don’t see any settings files for Capistrano Composer anywhere… `INFO [5d3cf5c3] Running /usr/bin/env composer install --no-dev --no-scripts --quiet --optimize-autoloader on 192.232.216.159 DEBUG [5d3cf5c3] Command: cd /home3/jaace/public_html/workflow4/releases/20131216155517 && /usr/bin/env composer install --no-dev --no-scripts --quiet --optimize-autoloader DEBUG [5d3cf5c3] /usr/bin/env: composer: No such file or directory` --- ## Post 26 by @swalkinshaw — 2013-12-16T17:15:09Z This goes back to your other issue where Capistrano doesn’t use an interactive shell so it won’t pick up any bash settings including your `.bash_profile`. What you want is the command map part of SSHKit (Capistrano is built on top of it). Basically just add this to your `deploy.rb` (or stage specific config): ``` SSHKit.config.command_map[:composer] = "/path/to/composer" ``` Then just running `execute :composer, :install` will look up the `composer` command in the command map and expand it to the full path! --- ## Post 27 by @Jaace — 2013-12-16T17:43:34Z Thanks, that seemed to work! I was trying my own task for composer\_install before you responded – just changing that command\_map is much cleaner. It seems to have worked, though it’s failing now due to “Connection refused -connect(2)” but only right before the end - so I don’t think it matters… `DEBUG [1bd13f8a] Running /usr/bin/env if test ! -d /home3/jaace/public_html/workflow4/releases; then echo "Directory does not exist '/home3/jaace/public_html/workflow4/releases'" 1>&2; false; fi on xxx.xxx.xxx.xxx DEBUG [1bd13f8a] Command: if test ! -d /home3/jaace/public_html/workflow4/releases; then echo "Directory does not exist '/home3/jaace/public_html/workflow4/releases'" 1>&2; false; fi cap aborted! Connection refused - connect(2)` I checked my other deploy test that wasn’t using Composer and this is right before it writes to the revisions.log, so I suppose it’s not super important as everything else was done. --- ## Post 28 by @swalkinshaw — 2013-12-16T19:37:45Z That’s really weird. I guess as long as the deploy completes (`current` symlink is updated) then it doesn’t matter much. But still weird! You may not have enjoyed it, but it’s probably good for other people that you went through some of these problems. Since we have some solutions to some common questions. --- ## Post 29 by @Jaace — 2013-12-16T20:02:47Z I’m posting in the Capistrano Github to see if they can shed any light on this issue – and then it’s on to see if I can migrate my local database over to the staging database, so the fun continues! Thanks for all of your help --- ## Post 30 by @Jaace — 2014-01-30T14:42:47Z Quick Vagrant question: When you’re using Vagrant, do you keep Composer on your local machine and use it from there or do you install it on your Vagrant VM? I figure it’s Composer on local (just like Capistrano)? Thanks for any insight! --- ## Post 31 by @swalkinshaw — 2014-01-30T17:55:42Z Ideally it should be installed on the VM. Mostly because if you’re using some config management for the VM like Chef, Puppet etc, those configs should be used for your production/staging servers as well. Which obviously those wouldn’t be connected to your local computer via a shared folder. So I’d get in the habit on NOT relying on local programs. Capistrano is different because it’s also local when deploying to remote servers. --- ## Post 32 by @Jaace — 2014-01-30T18:05:04Z OK I think I understand, so the best practice for you is to keep Capistrano on the local machine and Composer, Grunt, WP-CLI, etc on the Vagrant side? I don’t know enough about Puppet or Chef yet – will need to look into those maybe. I’m looking into Varying Vagrant Vagrants right now - so much information to take in but it all seems like it will be so useful once I understand it completely. Thanks for the response! --- ## Post 33 by @swalkinshaw — 2014-01-30T18:34:55Z If Grunt is part of your deploy process (meaning you run it on the remote server) then yes it should exist on the VM/remote server. WP-CLI is debatable I guess. Depends if you use it as part of your server provisioning process. The Chef configs we use for Vagrant use WP-CLI to run `core install` so in that case, it’s needed on the VM/server. --- ## Post 34 by @intelligence — 2014-03-29T11:55:24Z Just finished watching your Capistrano screencast and everything is really coming together for me now. Been worried that it was gonna be  cumbersome (as the cowboy coder that I am) so I’ve been avoiding to read up on it. Super happy that you’ve given me these tools to progress my development skills. If I hadn’t been a fan of Roots since long before I seriously doubt that I would ever leave the security and comfort of the ways I knew before. Thanks alot for making me :slight_smile: --- ## Post 35 by @intelligence — 2014-03-29T23:38:40Z Seeing some errors on my initial deploy, gave me these errors but still deployed successfully ``` DEBUG [a1532ffa] Running /usr/bin/env [-L /var/www/some.url/releases/20140329233206/.env] on x.x.x.x DEBUG [a1532ffa] Command: [-L /var/www/some.url/releases/20140329233206/.env] DEBUG [a1532ffa] Finished in 0.064 seconds with exit status 1 (failed). DEBUG [8e5999f0] Running /usr/bin/env [-f /var/www/some.url/releases/20140329233206/.env] on x.x.x.x DEBUG [8e5999f0] Command: [-f /var/www/some.url/releases/20140329233206/.env] DEBUG [8e5999f0] Finished in 0.062 seconds with exit status 1 (failed). DEBUG [f0e5eb18] Running /usr/bin/env [-L /var/www/some.url/releases/20140329233206/web/app/uploads] on x.x.x.x DEBUG [f0e5eb18] Command: [-L /var/www/some.url/releases/20140329233206/web/app/uploads] DEBUG [f0e5eb18] Finished in 0.063 seconds with exit status 1 (failed). ``` What could it be? --- ## Post 36 by @swalkinshaw — 2014-03-30T15:03:32Z `.env` and `web/app/uploads` are both in `shared_files`/`shared_dirs` and I think I remember having a problem like that if `.env` didn’t exist when you first deployed it would error. And since `.env` doesn’t exist in the repo by default (it’s ignored), you’d need to put it on the server manually the first time. --- ## Post 37 by @intelligence — 2014-03-30T15:05:29Z Strangely it’s not throwing any more errors, was just the initial one! --- ## Post 38 by @intelligence — 2014-03-30T23:30:35Z Noticed that the deployment deletes my .htaccess (manually created on the prod server). Is it supposed to do that? And how should I manage .htaccess otherwise? --- ## Post 39 by @swalkinshaw — 2014-03-31T00:04:09Z If you want your `.htaccess` file to persist across deploys it should be added to the `shared_files`. See [Proper way to handle htaccess files in each environment](http://discourse.roots.io/t/proper-way-to-handle-htaccess-files-in-each-environment/1282/4) --- ## Post 40 by @intelligence — 2014-03-31T12:16:30Z Thanks! Maybe would be an idea to add that to the Bedrock Read me? [https://github.com/roots/bedrock#deployment-steps](https://github.com/roots/bedrock#deployment-steps) --- ## Post 41 by @swalkinshaw — 2014-03-31T14:41:56Z What I really need to do is get the Wiki going since the README is already massive. --- ## Post 42 by @ravikumarg — 2014-05-19T14:48:49Z Hello Scott. It is a very informative screencast for Bedrock and helped me to home in on the basics. When extending Bedrock to include npm install and running it for the first time, I get the following error (extracted only the last few lines). `INFO [f55ebc5e] Running /usr/bin/env composer install --no-dev --prefer-dist --no-interaction --quiet --optimize-autoloader on example.com DEBUG [f55ebc5e] Command: cd /srv/www/example.com/releases/20140519134039 && ( WP_ENV=staging /usr/bin/env composer install --no-dev --prefer-dist --no-interaction --quiet --optimize-autoloader ) INFO [f55ebc5e] Finished in 1.123 seconds with exit status 0 (successful). DEBUG [fa0db4ea] Running /usr/bin/env if test ! -d /srv/www/example.com/current/web/app/themes/roots; then echo "Directory does not exist '/srv/www/example.com/current/web/app/themes/roots'" 1>&2; false; fi on example.com.me DEBUG [fa0db4ea] Command: if test ! -d /srv/www/example.com/current/web/app/themes/roots; then echo "Directory does not exist '/srv/www/example.com/current/web/app/themes/roots'" 1>&2; false; fi cap aborted! SSHKit::Command::Failed: if test ! -d /srv/www/example.com/current/web/app/themes/roots; then echo "Directory does not exist '/srv/www/example.com/current/web/app/themes/roots'" 1>&2; false; fi exit status: 1 if test ! -d /srv/www/example.com/current/web/app/themes/roots; then echo "Directory does not exist '/srv/www/example.com/current/web/app/themes/roots'" 1>&2; false; fi stdout: Nothing written if test ! -d /srv/www/example.com/current/web/app/themes/roots; then echo "Directory does not exist '/srv/www/example.com/current/web/app/themes/roots'" 1>&2; false; fi stderr: Nothing written` It seems that the composer/npm task is getting invoked before the current symlink is created for the first time. If I comment out the lines `require 'capistrano/npm'` and `require 'capistrano/grunt'` in the Capfile (and the line `before 'deploy:updated', 'grunt'` in the deploy.rb file) , the remote deployment completes successfully with the current symlink being generated correctly. Subsequent runs of Capistrano, after the inclusion of the above commented lines, results in a successful deploy as well (albeit after some tweaking of folder permissions through a separate ssh terminal). Has anyone else run across this issue? Is it related to the permissions of the user (I created a new user called deploy as given in the Capistrano website)? Thanks in advance. Ravi --- ## Post 43 by @swalkinshaw — 2014-05-19T21:15:08Z Could you post a [Gist](https://gist.github.com/) of your `deploy.rb` file? It shouldn’t matter that it happens before the `current` symlink because the Grunt extension (and npm) are set to use `release_path` by default which is the direct path to the release like `/releases/20140519120005`. --- ## Post 44 by @ravikumarg — 2014-05-20T03:22:41Z Thanks for the quick response. Here is the [gist](https://gist.github.com/raytara/6d78901e5c1d228a044e) of my deploy.rb file. --- ## Post 45 by @swalkinshaw — 2014-05-20T03:47:28Z Think it might be because of how you’re setting the `theme_path` variable. In Capistrano, things like `release_path` aren’t set until a deploy runs so you can’t directly reference it. You need it to be evaluated later so just wrapping it in a lambda (anonymous function basically) works. L21 here: [https://gist.github.com/swalkinshaw/17232e86d0b3d709095a](https://gist.github.com/swalkinshaw/17232e86d0b3d709095a) edit: and if I had it set like you did in my screencast then I apologize. Hard to update screencasts with “bug fixes”. However, the README in the npm/Grunt gems reflect using lambda ([https://github.com/roots/capistrano-grunt](https://github.com/roots/capistrano-grunt)) --- ## Post 46 by @ravikumarg — 2014-05-25T08:34:15Z I fixed the construct of the `theme_path` variable, as suggested, with the lambda wrapper. But I still get the error from the `npm:install` task that seems to check for the theme folder structure using the current symlink that does not exist for a first time install. See the following gist of the error message. “_Tasks: TOP =\> deploy:updated =\> npm:install (See full trace by running task with --trace) The deploy has failed with an error: #\&2; false; fi stdout: Nothing written if test ! -d /srv/www/example.com/current/web/app/themes/roots; then echo “Directory does not exist ‘/srv/www/example.com/current/web/app/themes/roots’” 1\>&2; false; fi stderr: Nothing written_” Anyone else facing this very same issue (on a first time install)? Could it be related to the SSHKit settings or the user permissions on my server root folder? --- ## Post 47 by @btamm — 2014-06-06T22:14:18Z Scott, I downloaded the video to get help. I am stuck on the deploy step. For now, I am skipping staging and am trying to deploy to production. When I run bundle exec cap production deploy, it connects to bitbucket just fine and when it starts trying to make the ‘shared’ and ‘releases’ directory, it fails with "mkdir: cannot create directory ‘/var/www/brandontamm.com/shared’: Permission denied" Same error for releases directory. I have a user:group deploy:www. The directory I am writing to is owned by www-data:www-data. I am nervous about changing ownerships without a little guidance - can you help me on this one? All I want to do is deploy code, not manage systems :frowning: --- ## Post 48 by @btamm — 2014-06-06T22:17:58Z Also - I am a bit confused on the .env file and the environments folder. Where do I change the database and URL - I am assuming I copy/paste the whole block in the .env file so I have one block for development and one block for production? Is there anything to change in the config/environment files? --- ## Post 49 by @swalkinshaw — 2014-06-07T03:41:22Z So you’re deploying with user `deploy` in group `www`? `/var/www/brandontamm.com` obviously needs to share either its user or group owner with the user you’re deploying with. One solution is just adding the `deploy` user to group `www-data` and then you don’t need to change directory permissions. --- ## Post 50 by @swalkinshaw — 2014-06-07T03:43:38Z You probably don’t need to change anything in the environments folder as they’re already set up to read the env vars set from the `.env` file. Your local `.env` file most likely should have development settings. Then on your production server you can just manually create it with prod values. There’s some more info in this issue: [https://github.com/roots/bedrock/issues/18](https://github.com/roots/bedrock/issues/18) --- ## Post 51 by @ajmalafif — 2014-06-10T15:49:57Z I get this error running `bundle exec cap staging deploy`: `sudo: no tty present and no askpass program specified` I’m not quite sure what’s causing since I am quite sure the settings and configuration was all taken care of. Any help and pointers? --- ## Post 52 by @swalkinshaw — 2014-06-10T20:01:07Z Are you using Windows? OS X? See here: [https://groups.google.com/forum/#!topic/capistrano/554ehbCE45o](https://groups.google.com/forum/#!topic/capistrano/554ehbCE45o) --- ## Post 53 by @ajmalafif — 2014-06-11T02:39:59Z Hey @swalkinshaw , I am using OS X. Thanks for the pointer, Scott. So far can’t figure out how to put this inside: ``` default_run_options[:pty] = true ``` any of the deploy.rb or staging.rb. Figuring out as we speak. Will share my findings and solutions if I beat anyone to it. Thanks again! --- ## Post 54 by @ajmalafif — 2014-06-11T05:28:55Z From the looks of it, my option is to have passwordless sudo or perhaps figure out how to make Capistrano can accept my sudo password. Right now it stops but doesn’t capture when I enter it. Will update more findings or solutions. UPDATES: - Managed to work it by doing passwordless sudo. I think I’m close now. It looks like in the docs it says I should point my vhost to `/path/to/app/current/web` but somehow on my Nginx setup it gives me 500 error code. I tried `/path/to/app/web` but that means it doesn’t reflect whatever i’m pushing from local. It’s a bare WP install rather than the one I updated and pushed from local to cloud (my case I’m using Github). Out of idea I restart server each time I changed any configuration. Will share further findings/solutions. --- ## Post 55 by @btamm — 2014-06-12T19:07:34Z Scott, Your video is very well done, however, setting up the remote server’s users/groups/permissions for capistrano and nginx seems to be causing issues for me (and others). After spending hours to get the ssh keys and users setup on my server, I (and ajmalafif from above) am having issues with capistrano creating and owning files and folders as user ‘deploy.’ However, nginx is setup as www-data:www-data. Deploy does belong to the same group ‘www-data’ . So, I manually changed ownership of the folders/files to user ‘www-data’ from ‘deploy’ in order to deploy successfully. It worked, but I found that deploys fail to delete releases after the 5th release due to the manual ownership change. Can you provide insight into properly dealing with users/groups/permissions for capistrano and nginx to work together as intended? Thanks, Brandon --- ## Post 56 by @swalkinshaw — 2014-06-12T23:35:35Z > [@ajmalafif](#): > > /path/to/app/current/web That’s correct. If you’re getting a 500 error there should be an error somewhere. Check nginx’s error log. Pretty hard to debug otherwise. --- ## Post 57 by @ajmalafif — 2014-06-13T07:24:46Z @swalkinshaw Thanks I think I got it now. It was the `shared/.env` file. There are few gotchas for my specific setup. I keep track of them and gonna share like my DigitalOcean’s list later. I’m still half way into implement the whole setup (use s3 and cloudfront for assets files) and extra security setup for this EC2 setup. Thanks again that screencast helps bridge a lot of stuffs that isn’t too clear (i’m a visual learner). Thanks again for help and concern Scott! btw what the point of having that repo\_url? Doesn’t it mean it will only reflect my github repo with specified branch, rather than the repo I `cap deploy` from local? Somehow I think it’s good practice to reflect on github first rather than what’s on local. I use CircleCI for some Rails project with others, helps on syncronization of our works better (but then again bcos Rails have integration test and all). --- ## Post 58 by @swalkinshaw — 2014-07-17T14:08:35Z Sorry for the delay on this, this thread got buried. Capistrano’s entire purpose is to deploy a codebase from an SCM (like Git). It will always reflect that `repo_url` and not what you have locally. I guess I’m confused by your question because whatever you set in `repo_url` will (most likely) be the local repo you have checked out as well. --- ## Post 59 by @alexandcote — 2014-08-10T19:18:18Z I have the same issue. Did you find a solution ? Thanks Alex --- ## Post 60 by @thiago — 2014-12-09T14:29:45Z ### Blood, sweat and tears After hours and hours of tackling all sorts of issues, mainly to do with Plesks default permissions on my DV server over at _MediaTemple_, I have finally managed to do a **successful deploy**. Yet it never ends. * * * ### One final Issue What I am having trouble with now is getting Capistrano set the `application.php` to work well with my database. I have added `.env` to where it should be but the settings are not being translated over. * * * ### Debug These are the only errors I am now receiving: ``` DEBUG[966c9c4a] Running /usr/bin/env [-L /var/www/vhosts/domain.com/dev.domain.com/www/releases/20141209142224/.env] on dev.domain.com DEBUG[966c9c4a] Command: [-L /var/www/vhosts/domain.com/dev.domain.com/www/releases/20141209142224/.env] DEBUG[966c9c4a] Finished in 0.533 seconds with exit status 1 (failed). DEBUG[92249387] Running /usr/bin/env [-f /var/www/vhosts/domain.com/dev.domain.com/www/releases/20141209142224/.env] on dev.domain.com DEBUG[92249387] Command: [-f /var/www/vhosts/domain.com/dev.domain.com/www/releases/20141209142224/.env] DEBUG[92249387] Finished in 0.339 seconds with exit status 1 (failed). DEBUG[f6c86024] Running /usr/bin/env [-L /var/www/vhosts/domain.com/dev.domain.com/www/releases/20141209142224/web/app/uploads] on dev.domain.com DEBUG[f6c86024] Command: [-L /var/www/vhosts/domain.com/dev.domain.com/www/releases/20141209142224/web/app/uploads] DEBUG[f6c86024] Finished in 0.359 seconds with exit status 1 (failed). DEBUG[02f255ef] Running /usr/bin/env wp core is-installed on dev.domain.com DEBUG[02f255ef] Command: cd /var/www/vhosts/domain.com/dev.domain.com/www/releases/20141209142224 && ( WP_ENV=staging /usr/bin/env wp core is-installed ) DEBUG[02f255ef] /usr/bin/env: wp: Permission denied DEBUG[02f255ef] Finished in 0.371 seconds with exit status 126 (failed). ``` _EDIT: a few hours later_ As it turns out most the aforementioned failures were actually doing their job. Hours of trial and error and google searching led me [here](http://stackoverflow.com/questions/21617458/usr-bin-env-and-capistrano-3-failures-in-rails-deployment). The issue that **did** need a fix however was the permission denied error when attempting to execute `/usr/bin/env :wp` To override SSHKit using wp-cli in this folder, I added the following line before `:deploy do` : ``` SSHKit.config.command_map[:wp] = "/usr/local/bin/wp/wp-cli.phar" ``` --- ## Post 62 by @swalkinshaw — 2014-12-10T04:34:10Z Is everything working now? --- ## Post 63 by @thiago — 2014-12-10T18:19:31Z Yes, finally! Just when I was at the very brink, my laptop decided to co-operate! I have even moved to mariadb for testing and because this little laptop can’t handle running a vbox alongside phpstorm (I have already reduced its max ram usage to under 300mb) I am using [brewstack](https://gist.github.com/shrop/3698170). It will have to do for now! I am managing all my database with SequelPro, goodbye phpmyadmin forever! I will keep you posted on any issues if I run into them! --- ## Post 64 by @bpurdyiv — 2015-09-14T01:40:13Z Thanks for the awesome screencast! When deploying a site that uses composer to manage wordpress and plugins, would there be any issues adding the vendor dir to the linked dirs? --- ## Post 65 by @swalkinshaw — 2015-09-14T01:53:10Z That’s a common question and the best discussion I’ve had about this is on my npm Capistrano gem (same concept applies): [https://github.com/capistrano/npm/issues/7](https://github.com/capistrano/npm/issues/7) --- ## Post 66 by @andrew40 — 2017-05-09T16:56:23Z I am probably out of place stating this here, but i think the screencast needs to be updated as on current Mac’s OSX the new System Integrity Protection prevents you from installing gems called/that are rootless. You get the error message ``` ERROR: While executing gem ... (Errno::EPERM) ``` so to install Bundle one has to: ``` sudo gem install -n /usr/local/bin GEM_NAME_HERE ``` which then throws up all sorts of issues when trying to run bundle commands such as ``` Could not locate Gemfile or .bundle/ directory ``` so at this point in time i am stuck about 11 minutes into the screencast!! --- ## Post 67 by @swalkinshaw — 2017-05-09T19:24:06Z I’ll have to go back and watch the screencast again to see how I talk about installing gems, but yeah `sudo` shouldn’t be used here. The way around it is to just use `bundle` without it. See [https://gorails.com/setup/osx/10.12-sierra](https://gorails.com/setup/osx/10.12-sierra) for instructions on using `rbenv` to install Ruby. It’s more work but guarantees no issues with `sudo` or permissions. edit: ignore the rest about Rails. Just the part about rbenv + bundler itself. --- ## Post 68 by @deodat — 2019-09-01T09:32:21Z Hello, I just bought your screencast but it’s … empty ! Can you help ? Regards, David --- ## Post 69 by @ben — 2019-09-01T15:31:02Z This screencast is now [available for free on our YouTube channel](https://www.youtube.com/channel/UC00DsMDpjKxYCXGVStFiCPg) :slight_smile: