Geoff, could you please provide me with some additional information
about the multistaging recipes? I can find the capistrano-ext package
on rubyforge, but I don't see any documentation anywhere.
I wasn't clear with my exact issue that I'm having (my brain was mush
yesterday after fiddling with this and other projects for hours):
============8< SNIP =================
role :prod, 'prod.domain.com'
role :staging, 'stage.domain.com'
role :database, 'db1.domain.com'
role :auth, 'ldap.domain.com'
namespace :deploy do
task :production, :roles => :prod do
deploy
end
task :staging, :roles => :staging do
deploy
end
task :deploy do
#deploy stuff
end
end
=======8< SNIP ================
My issue is that I need to do the exact same thing on my staging and
production servers, except for slightly different pre and post setup,
but they both put the application in the same place and the basic
deploy code is identical. So when I call deploy from either the
staging or production tasks, the deploy script gets run on ALL roles
that I have defined. I've got about 9 servers defined in my Capfile,
so this isn't acceptable.
Since I've already defined my roles at the top, I'd hate to have to
hard-code the hostnames in the production and staging tasks when
setting ENV['HOSTS']. Another option would be if I could somehow set
the HOSTS env by using the roles' nickname (ie: :production rather
than prod.domain.com).
So my real need is for there to be a way to have a called task inherit
the roles of the calling task. For now, I've just hardcoded the
hostnames in my tasks.
Thanks!
...spike
On Jun 20, 5:02 am, Geoff <[EMAIL PROTECTED]> wrote:
> While I'd thoroughly recommend using the capistrano-ext multistaging
> recipes for your multistaging work but calling tasks from other tasks
> was the question posed.
>
> Task names like
>
> deploy:production:whatever
>
> are exposed within Cap as
>
> deploy.production.whatever
>
> I use something like this in one of my recipes to run all tasks in
>
> project:copy:config
>
> I have a project:copy:configs task which looks like this
>
> namespace :copy do
> task :configs do
> # Current namespace: :copy
> # All config copy tasks should be kept under the
> # +project:copy:config+ namespace.
> # They will be executed automatically after the
> # deploy:update_code task by this task.
> config.tasks.each do |name, task|
> config.send(task.name)
> end
> end
> end
>
> thats one example. If you wanted to change the ENV['HOSTS'] you could
> have something like
>
> task :whatever do
> ENV['HOSTS'] = "something"
> top.deploy.my_app
> end
>
> Not that top rewinds the namespaces to the top level. If
> your :whatever task was in the :deploy namespace then could just call
> the my_app task. If you are in the deploy:production namespace then
> you could call parent.my_app.
>
> Hope that helps.
>
> On 19 Jun, 23:57, spike grobstein <[EMAIL PROTECTED]> wrote:
>
> > yeah, the namespacing thing is what I'm trying to take advantage of.
>
> > I also spent about 2 hours today going through the capistrano code
> > trying to figure out if there was some way I could access the roles
> > that are getting passed to the task so I could call something like:
>
> > ENV['HOSTS'] = this_tasks_roles
>
> > What I'm going to have to do is have 2 tasks that are identical except
> > for their names and roles. It's not gonna be very DRY and it's not
> > gonna be very pretty, but it'll work and the interface will be
> > prettier than passing HOSTS on the commandline.
>
> > I just wish there was a way of calling a task from the context of
> > another task so it uses the same roles as the calling task.
>
> > Thanks.
>
> > ...spike
>
> > On Jun 19, 5:30 pm, Jamie Orchard-Hays <[EMAIL PROTECTED]> wrote:
>
> > > I have an old cap 1.4.1 script that I used like this:
>
> > > if ENV['DEPLOY'] == 'production'
> > > puts "*** Deploying to the PRODUCTION servers!"
> > > set :application, "production-web"
> > > set :rails_env, "production"
> > > set :mongrel_port, "8000"
> > > set :mongrel_environment, "production"
> > > else
> > > puts "*** Deploying to the STAGING server!"
> > > set :application, "staging-web"
> > > set :rails_env, "staging"
> > > set :mongrel_port, "8010"
> > > set :mongrel_environment, "staging"
> > > end
>
> > > But with the namespacing in Cap 2, seems like you could just define
> > > this stuff inside your namespace:
>
> > > namespace :deploy do
> > > namespace :production do
> > > # set your environment here
> > > # reference original tasks here your tasks here
> > > end
> > > end
>
> > > I'm not sure it's worth the work. With the environment variable, you
> > > just call that before you call your cap tasks on the command line. In
> > > my original scheme, I have staging be default, then production doesn't
> > > get deployed to accidentally.
>
> > > Jamie
> > > On Jun 19, 2008, at 2:55 PM, spike grobstein wrote:
>
> > > > Hi,
>
> > > > I'm using capistrano to deploy [non-rails] applications to our server
> > > > environment. Because our SVN server lives on the LAN, but the entire
> > > > application environment lives on a separate private network accessible
> > > > only through a gateway machine, capistrano is an ideal tool for
> > > > pushing updates to the various applications.
>
> > > > I'm running into an issue where I have a task that I want to call but
> > > > on different hosts (ie: deploying to our staging and production
> > > > servers). Right now, I'm doing it like this:
>
> > > > cap deploy:my_app HOSTS="production1.server.com"
>
> > > > however, I'd much prefer to call it like this:
>
> > > > cap deploy:my_app:production
> > > > or
> > > > cap deploy:my_app:staging
>
> > > > I created 2 tasks, one for staging and one for production, each with
> > > > their roles set appropriately, and each calling a "deploy_my_app"
> > > > task, but it tries to deploy the app to all servers.
>
> > > > Is there a way to call deploy_my_app, but only have it execute on the
> > > > servers with the roles defined in the calling task? I can't use
> > > > "ENV['HOSTS'] = :production", since it requires that I supply it with
> > > > a hostname/FQDN rather than a symbol referencing it.
>
> > > > any help?
>
> > > > tia.
>
> > > > ...spike
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
