Fork me on GitHub

Capistrano 2.0 Preview 3

Posted by Jamis on June 15, 2007 @ 09:10 PM

Alright, we’re nearing the finish line! Capistrano 2.0 Preview Release #3 is now available.

Capistrano is a utility for automating the execution of tasks on one or more remote machines. You can read all about it at www.capify.org.

To install Preview #3, you’ll need to grab it from the Rails beta gem server:


gem install -s http://gems.rubyonrails.org capistrano

Accompanying PR3 is a new page of documentation on the capify.org site: Capistrano Basics. This walks you through the major features of Capistrano, but does not touch on deployment. This makes it a great introduction for those wanting to use Capistrano in non-deployment scenarios.

Preview #3 includes the following changes and enchancements:

Feature: Mercurial and CVS are now supported out of the box. Just set your :scm variable to :mercurial or :cvs, like so:

1
2
3
set :scm, :mercurial
# or
set :scm, :cvs

Thanks to Tobias Luetke and Matthew Elder for the Mercurial module, and Brian Phillips for the CVS module.

Feature: There is now a :default_environment variable, which is a hash that can be used to set environment variables that should be present for all commands that are executed. For instance:

1
2
default_environment["PATH"] =
  "/bin:/usr/bin:/usr/local/bin:/home/jamis/bin"

Feature: All commands are now explicitly invoked via “sh”, which means that even if your default user shell is non-POSIX (e.g., tcsh, csh, etc.), you can use Capistrano just fine. Note that if you were using tcsh or csh syntax in your Capistrano scripts, you now need to set the :default_shell variable to use your (non-POSIX) shell of choice:


set :default_shell, "/usr/bin/tcsh"

Feature: You can declare empty roles, and Capistrano won’t complain. This is useful for predeclaring roles that need to exist (because task definitions depend on them), but which might not have any servers in them (depending on runtime conditions).

Feature: A username and port specified with the server definition (e.g., “fred@some.server.com:1234”) now take precedence over the :username and :port settings in the ssh_options hash, rather than the other way around. This lets you set a general default via ssh_options, and override on a per-server basis in the server definitions themselves.

There are several other minor changes and fixes as well; you can read the CHANGELOG for all the gory details.

Posted in Announcements

Comments

Have something to add? Click here to leave a comment.

17 Jun 2007

1. Duncan Robertson said...

Been using mercurial for a while using Marcus Ahnve’s plugin. Thanks for this welcome addition.

18 Jun 2007

2. Amr said...

I’m getting a Zlib buff error, and my gem system is uptodate 0.9.4 anyone else run into this? thanks,

3. Peter McLain said...

I had net-ssh 1.0.10 installed and was getting errors like:

$ cap—help /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require’: no such file to load—net/ssh/service/agentforward/services (LoadError)

I updated to net-ssh 1.1.2 and cap started working. You may want to update SSH_REQUIRED for the new version.

4. Jamis Buck said...

Peter, that bug has been fixed in cap edge, and cap2 final will run fine against Net::SSH 1.0.10.

21 Jun 2007

5. josh said...

Hmm, I’m also getting the same error as Amr.

gem install -s http://gems.rubyonrails.org capistrano

ERROR: While executing gem … (Zlib::BufError) buffer error

This is on a windows machine with: capistrano (1.99.1) highline (1.2.8) net-ssh (1.1.2)

gem—version 0.9.4

6. Mike Diehn said...

Love the new cap, Jamis – thanks!

I’m using it to automate sysadmin tasks for a few Ubuntu 7.04 and Debian Etch servers. Got stuck because “cap deploy” kept bombing when I ran it on my Debian Etch administration server. Finally figured it out:

On the deploying host, capistrano’s “deploy” needs to be able to execute

"svn info -r"

Debian Etch’s version of Subversion is 1.1.x – too old for “-r” on svn info. Dash r appeared in subversion 1.2.

So, that seems like a dependency that folks on Debian Etch or older will run into.

22 Jun 2007

7. Amr said...

Hey Josh, looks like the XP side is out of luck until maybe the next version of gem comes out. See Jamis’ response to my post on the capistrano newsgroup.

27 Jun 2007

8. Jamis said...

For those of you having problems with RubyGems on Windows, you can work around the issue by patching RubyGems yourself, as described here:

http://groups.google.com/group/capistrano/msg/ca6161f30a9ebb70

Hopefully, that fix (or a similar one) will find its way into RubyGems itself eventually.

9. Anko said...

How long before version 2.0 comes out?

Anko

28 Jun 2007

10. Anko said...

That is to say, is there a roadmap? Sorry if I sounded pushy in that last post!

Anko

11. Jim said...

Consider this my vot to “hold you to that!” (http://weblog.jamisbuck.org/2007/6/12/capistrano-and-leopard)

I’m eager for Cap2 and its the end of the month ;-)

12. Jamis said...

@Anko, I just released preview release #4 tonight, and I plan to release cap2 final next week, probably towards the end of the week, to let pr4 percolate a bit.

@Jim, thanks! I might miss the end of the month, but I’ll hit the beginning of next. :)