Skip to content

-f changes behavior of multistage #231

Closed
koppen opened this Issue Jun 26, 2012 · 5 comments

2 participants

@koppen
koppen commented Jun 26, 2012

With the following deploy.rb:

require 'bundler/capistrano'

# Configure multistage extension
set :stages, %w(staging production)
set :default_stage, "staging"
require 'capistrano/ext/multistage'

task :uname do
  run "uname -a"
end

I am getting some unexpected behavior. The simple case works fine:

$ cap production uname
  triggering load callbacks
* executing `production'
  triggering start callbacks for `uname'
* executing `multistage:ensure'
* executing `uname'
[...]

The uname task is run on the production stage as expected. However, if I explicitly specify my Capfile, the task is also run on the staging stage, which is definitely not expected.

$ cap -f Capfile production uname
  triggering load callbacks
* executing `staging'
* executing `production'
  triggering start callbacks for `uname'
* executing `multistage:ensure'
* executing `uname'
[...]

The Capfile contains

load 'deploy' if respond_to?(:namespace) # cap2 differentiator
load 'config/deploy'

This is with Capistrano v2.12.0 on both Ruby 1.8.7 and 1.9.3.

@koppen
koppen commented Jun 26, 2012

Digging further, it seems that if I remove

set :default_stage, "staging"

cap -f Capfile uname works as expected without invoking the staging task.

@carsomyr
carsomyr commented Aug 7, 2012

@kopen Do you think these lines are the culprit?

@koppen
koppen commented Aug 7, 2012

@carsomyr Yes, those are exactly it, good find.

Looks like the assumption that ARGV.first contains the stage name is the culprit. That might be true in the generic cap production deploy case, but any command line options breaks it - for example

cap -n uname #=> ARGV.first == "-n"
cap -f Capfile uname #=> ARGV.first == "-f"
@carsomyr
carsomyr commented Aug 7, 2012

@koppen This is why I made a rather large pull request: Attempts at parameterizing task execution so far have been ad hoc. For now, sit tight and try to work around the problem.

@carsomyr carsomyr closed this Aug 7, 2012
@koppen
koppen commented Aug 8, 2012

The workaround is fairly easy, and for anybody googling their way to this issue: Just don't set the :default_stage variable in your deploy.rb.

Sure, it means you have to always specify a stage, but that's probably the wisest thing to do anyways.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.