Deploying WordPress with Capistrano screencast

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:

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

What I really need to do is get the Wiki going since the README is already massive.

2 Likes

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

Could you post a Gist 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.

Thanks for the quick response. Here is the gist of my deploy.rb file.

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

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)

1 Like

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: #<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 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?

1 Like

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:

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?

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.

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

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?

Are you using Windows? OS X?

See here: https://groups.google.com/forum/#!topic/capistrano/554ehbCE45o

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!