Jamis,
A couple of day ago, you suggested using a setup as follows to deploy
an app multiple times on same machine.
Suggested Approach:
http://groups.google.com/group/capistrano/browse_thread/thread/56a2b4a2b95f27d2/c36c9f71dfc94071
I tried your suggestion and here is what I found:
before 'stop_here', 'print_variables'
task :install_staging do
set :deploy_to, "/home/rails/#{application}_staging"
end
desc 'a fake task that stops capistrano'
task :stop_here do
fail "stop here."
end
Where 'print_variable' is something like:
task :print_variables, :roles => :app do
%w(application deploy_to).each do |k|
puts "#{k} => #{fetch(k.to_sym)}"
end
(variables.keys.select { |k| /stage/ =~ k.to_s }).each do |k|
puts "#{k} => #{fetch(k.to_sym)}"
end
(variables.keys.select { |k| /path/ =~ k.to_s }).each do |k|
puts "#{k} => #{fetch(k.to_sym)}"
end
end
When I try 'cap install_staging stop_here' I get following
$ cap install_staging stop_here
triggering start callbacks for `install_staging'
* executing `multistage:ensure'
*** Defaulting to `staging'
* executing `staging'
* executing `install_staging'
triggering start callbacks for `stop_here'
* executing `multistage:ensure'
* executing `stop_here'
triggering before callbacks for `stop_here'
* executing `print_variables'
application => MyApp
deploy_to => /home/rails/MyApp_staging
stages => staging
stage => staging
default_stage => staging
releases_path => /home/rails/MyApp_staging/releases
shared_path => /home/rails/MyApp_staging/shared
current_path => /u/apps/MyApp/current
release_path => /home/rails/MyApp_staging/releases/20080722171150
./config/deploy.rb:18:in `load': stop here. (RuntimeError)
Note that, current_path is not what we expect it to be. This will
cause multiple installation for a given app will all share same
current_path. Won't this cause problem?
I am not sure however I believe that this is because of caching
implemented in Variable.fetch() method. current_path probably gets
evaluated before :deploy_to is set.
I needed something like:
set :rails_env, 'qa'
set :application, "PlantCollections_#{rails_env}"
In most common scenarios, :rails_env needs to be in deploy/
<stage_name>.rb (each stage needs a different environment).
The :application depends on :rails_env and has to be evaluated
after :rails_env has been set. So, I tried setting :application in
following ways:
1)
# in deploy.rb
set :application, Proc.new { "MyApp_#{rails_env}" }
# hoping Proc.new will cause delayed evaluation
# Result: unable to resolve 'rails_env' as method
2)
# in deploy.rb
set :application, Proc.new { "MyApp_#{fetch(:rails_env, "ignore")}" }
# hoping Proc.new will cause delayed eval and fetch is recommended way
to get variable's value
# Result: :application is set to "MyApp_ignore" which is not what we
want
3)
# in <stage__name>.rb
set :rails_env, 'staging'
set :application, "MyApp_#{rails_env}"
set :deploy_to, "/u/apps/#{application}"
# Result: :application has to be defined in deploy.rb file ...
None of these worked and reasons were understandable, I think :-)
So, here is what I ended up doing:
I got rid of lazy loading magic in multistage and included following
_at_the_top_ of my deploy.rb:
require 'palmtree/recipes/mongrel_cluster'
set :stage, "qa" unless variables[:stage]
# require 'capistrano/ext/multistage' - DONT USE multistage's lazy
loading - load stage-file readily - as follows:
location = fetch(:stage_dir, "config/deploy")
load "#{location}/#{stage}"
This would immediately load the stage specific deploy/<stage>.rb and I
could set :rails_env and :application in my <stage>.rb file as
follows:
set :rails_env, 'staging'
set :application, "MyApp_#{rails_env}"
set :deploy_to, "/u/apps/#{application}"
This does change how different can be invoked. So, I can no longer do
"cap <stage> <deploy_task>".
Instead, I have to to "cap -S <stage> <deploy_task>".
Here is what I get:
$ cap stop_here
* executing `stop_here'
triggering before callbacks for `stop_here'
* executing `print_variables'
application => MyApp_staging
deploy_to => /u/apps/MyApp_staging
stage => staging
releases_path => /u/apps/MyApp_staging/releases
shared_path => /u/apps/MyApp_staging/shared
current_path => /u/apps/MyApp_staging/current
release_path => /u/apps/MyApp_staging/releases/20080722174511
I am happy with what I've got. Is there anything utterly undesirable
about this approach?
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
