The maze book for programmers!
mazesforprogrammers.com

Algorithms, circle mazes, hex grids, masking, weaving, braiding, 3D and 4D grids, spheres, and more!

DRM-Free Ebook

The Buckblog

assorted ramblings by Jamis Buck

Capistrano 2.1

14 October 2007 — 3-minute read

After a much larger delay than I would have liked, Capistrano 2.1 is now available! There is a lot going on in this release, including some pretty exciting changes. As ever, install it via RubyGems with:


gem install capistrano

Here’s what’s new, roughly in order of magnitude:

No default PTY. Prior to 2.1, Capistrano would request a pseudo-tty for each command that it executed. This had the side-effect of causing the profile scripts for the user to not be loaded. Well, no more! As of 2.1, Capistrano no longer requests a pty on each command, which means your .profile (or .bashrc, or whatever) will be properly loaded on each command! Note, however, that some have reported on some systems, when a pty is not allocated, some commands will go into non-interactive mode automatically. If you’re not seeing commands prompt like they used to, like svn or passwd, you can return to the previous behavior by adding the following line to your capfile:


default_run_options[:pty] = true

Disable sh wrapping. Some shared hosts do not allow the POSIX shell to be used to execute arbitrary commands, which is what Capistrano has done since 2.0. If you’re on such a host, you can add the following line to your capfile:


default_run_options[:shell] = false

Capistrano will then run the command directly, rather than wrapping it in an “sh -c” command. Note, though, that this means that your own user shell on the remote hosts must be POSIX compatible, or you’ll get cryptic errors.

Git SCM support. Many thanks to Garry Dolley, Geoffrey Grosenbach, and Scott Chacon for their work on the new Git SCM module for Capistrano. If you’re a user of Git, you can now do:


set :scm, :git

Accurev SCM support. Thanks to Doug Barth, all you Accurev users can now enjoy Capistrano, too. Just do:


set :scm, :accurev

Rails’ Plugin Support. Capfile’s generated via the “capify” utility will now include a line that will autoload all recipes from vendor/plugins/*/recipes/*.rb. If you want this feature and you’ve already got a Capfile (and you don’t mind losing any changes you might have made to your Capfile), you can delete the Capfile and re-run “capify .”. Or, you can just add the following line to your Capfile, before the line that loads ‘config/deploy’:


Dir['vendor/plugins/*/recipes/*.rb'].each { |plugin| load(plugin) }

Windows-safe reads. Any time Capistrano needs to read a file’s contents, it will now use the “b” flag, so that binary reads on Windows do not corrupt the file.

Cap shell and sudo. The Capistrano shell now properly recognizes sudo commands and prompts for the password correctly.

Use `match’ to check dependencies. There is a new remote dependency method for deploy:check: “match”. You can now look for arbitrary regular expressions in the output of various commands to see if things are set up correctly:


depend :remote, :match, "rake -V", /version 0\.7/

Namespaces#top. Sometimes you’ll find yourself wanting to execute a task from within another task, but the parent namespace of the target task is conflicting with a similarly-named namespace, and things are breaking. You can now use the “top” method to jump to the top of the namespace hierarchy:

1
2
3
4
5
6
7
8
namespace :apache do
  namespace :deploy do
    task :restart do
      run "restart apache"
      top.deploy.restart
    end
  end
end

Other changes. There are lots of other, smaller bug fixes and changes, too:

  • Default to 0664 instead of 0660 on upload.
  • Fix deploy:pending to query SCM for the subsequent revision so that it does not include the last deployed change.
  • Prefer ‘Last Changed Rev’ over ‘Revision’ when querying latest revision via Subversion.
  • Explicitly require ‘stringio’ in copy_test.
  • When Subversion#query_revision fails, give a more sane error.
  • Don’t run the upgrade:revisions task on non-release servers.
  • Use the—password switch for subversion by default, but add :scm_prefer_prompt variable for those who’d rather not send the password on the command-line.
  • Use sudo -p switch to set sudo password prompt to something predictable.
  • Allow independent configurations to require the same recipe file within the same Ruby process.
  • Allow auth-caching of subversion credentials to be enabled via :scm_auth_cache.
  • Don’t let a task trigger itself when used as the source for an “on” hook.
  • Add version_dir, current_dir, and shared_dir variables for naming the directories used in deployment.
  • Use the :runner variable to determine who to sudo as for deploy:restart.
  • Change the “-h” output so that it does not say that “-q” is the default.

Enjoy! And please report any bugs on the Rails trac, with the component set to “Capistrano”.

Reader Comments

“Default to 0664 instead of 0660 on upload.”

Ouch!

It looks like you need default_run_options[:pty] = true for SVN to work on Windows. Otherwise, it simply asks for the password and never gets anywhere.

the :pty => true thing is actually immaterial to the OS you are deploying from. It depends on a variety of factors, including the remote OS version, whether the program doing the prompting supports interactive mode without a pty, and so forth.

I’ll be releasing an update soon in which :pty => true is the default, and you have to opt-out of the pty if you decide you don’t want it.

Good idea. I would suggest that (:pty => true) as a default for a dot release makes good sense since that is the previous and expected behavior.

I had to reinstall Capistrano after my Leopard upgrade and got version 2.1. My first push to a shared host resulted in many cryptic errors as a result of the :pty change. Luckily, the solution was easy. However, since I have to update a bunch of Capfiles and will surely be re-mystified in a few months when I work again on an old project I missed.

(BTW, great blog. Just found this the other day for the first time and have stumbled upon it twice more lately while searching for esoteric Rails stuff.)

Hi,

I’m using the multistage module. It has worked great except one problem: I can’t use test as name for one of the stages

set :stages, %w(development production test localtest)

throws error: /usr/lib/ruby/gems/1.8/gems/capistrano-2.1.0/lib/capistrano/configuration/namespaces.rb:97:in `task’: defining a task named `test’ would shadow an existing method with that name (ArgumentError)

The reason I’d like to use test so it is consistent with rest of rails naming convention: database.yml, environment.rb. Is there a way to get around this problem?

Thanks a lot,

Jen

Jamis,

Awesome work can’t wait to upgrade to cap 2.1!

Stop by

http://giantrobots.thoughtbot.com/2007/11/13/the-contest

when you got some free time. We’re giving away free copies

of our new book!

free stuff!

- jc

This PTY change caused problems for my calls to etc/init.d scripts/commands (they would hang after being run). So I had to do the ‘default_run_options[:pty]’ thing. Just thought I’d put that out there for google.

I’m getting the same error as Jen when using the recipe I found at http://devthatweb.com/view/deploy-any-project-using-capistrano-2. Sadly, no documentation exists out there to tell me what’s causing the problem. :(