Using Command Line Parameters w/ Rake and Capistrano

Posted by ryan
at 10:40 PM on Thursday, June 21, 2007

Almost every project I work on requires a small set of both custom rake tasks and capistrano recipes. Since my models are as fat as they can be, these tasks and recipes are usually quite slim and really only involve delegation to the appropriate model method. Ok, so apparently Ryan thinks he’s great because he religiously believes in fat models – woohoo – that’s last year’s news. What I really want to talk about is that I am always needing to pass in parameters from the command line to these tasks, and everytime I struggle finding the documentation on how to properly do that.

So let’s try to figure this out once and for all.

Command line parameters in Rake

on Rake v0.7.2

This one’s easy. Options can be passed into rake by specifying key/value pairs on the rake command:


rake options:show opt1=value1

These command line options are then automatically set as environment variables which can be accessed within your rake task:

1
2
3
4
5
6
7
8
namespace :options do

  desc "Show how to read in command line options"
  task :show do
    p "option1 is #{ENV['opt1']}"
  end

end

I don’t love overloading the environment variables collection as a command line marshaller, but hey, it is what it is and it’s easy to use.

1
2
rake options:show opt1=value1
#=> option1 is value1

Ok, easy enough. Next.

Command line parameters in Capistrano

w/ Capistrano v1.4.1

Capistrano is a little different in that you need the -s command line switch for each key/value pair and you have a different way(s) of accessing these variables within your capistrano tasks. For instance, this is the capistrano version of the rake invocation example from earlier:


cap -a show_options -s opt1=value1

And you’ve got a couple of ways to get at these variables from within your capistrano task. The first is by referencing the variable name itself:

1
2
3
task :show_options do
  p "option1 is #{opt1}"
end

This is convenient, but you get a method_missing exception when you attempt to reference that variable when it hasn’t yet been set. The more reliable accessor method is by using the configuration object available to your capistrano tasks:

1
2
3
task :show_options do
  p "option1 is #{configuration[:opt1]}" if configuration[:opt1]
end

which will simply be nil if it doesn’t exist instead of choking like the previous, direct, access.

When you’re building a task library you’ll be wrapping your tasks in a Capistrano.configuration(:must_exist) block that yields the configuration object itself. So you can rename that lengthy configuration name to c if you’re the lazy type in that scenario:

1
2
3
4
5
6
7
Capistrano.configuration(:must_exist).load do |c|

  task :show_options do
    p "option1 is #{c[:opt1]}" if c[:opt1]
  end

end

So while this isn’t ground-breaking research here, I’ve had trouble finding concrete documentation on passing in values from the command line to Rake and Capistrano. So consider this a note to myself from the future… except that it’s from the past… to the future Ryan… which isn’t nearly as impressive.

tags: ruby, rubyonrails, rake, capistrano

Comments

Leave a response

  1. kamalJune 21, 2007 @ 11:49 PM

    Shouldn’t your capistrano example use opt1?

    cap -a options_show -s opt1=value1

  2. Ben PicklesJune 22, 2007 @ 06:19 AM

    i wonder if some combination of chaining tasks – ala http://errtheblog.com/post/33 – and rake’s “method_missing” – ala http://nubyonrails.com/articles/2006/07/28/foscon-and-living-dangerously-with-rake – would ease the flow?

    rule "" do |t|
      if /opt(\d+)$/.match(t.name)
        puts $1
      end
    end
  3. CNJune 22, 2007 @ 07:27 AM

    Nice post! simple and straight forward :) thx a lot

    One tiny question: shouldn’t the cap ‘cap -a options_show -s option1=value1’ command line ‘options_show’ be setup as options_show also in capistrano configuration? or is it intended to be the opposite way around.

  4. RyanJune 22, 2007 @ 08:57 AM

    Thanks for the typo corrections, guys:

    ^option1^opt1 ^options_show^show_options

  5. Ben ReubensteinJune 26, 2007 @ 11:46 AM

    One thing that got me was the -s and -S option. I wanted to set a value to switch which variables were used for the deploy task. -S is needed so the value is set prior to the tasks loading.

  6. Brandon KellyAugust 25, 2007 @ 05:19 PM

    The capital ‘S’ in -S is critical (at least on my windows box)... thanks for that tip. Whew.