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.
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
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”.
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.
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
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!
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.
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.
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
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!
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.
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!
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.
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 
2 Likes
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?
.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.
Strangely it’s not throwing any more errors, was just the initial one!
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?
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
2 Likes
Thanks! Maybe would be an idea to add that to the Bedrock Read me? https://github.com/roots/bedrock#deployment-steps