If you want to invoke deploy:update on a specific role: cap ROLES=foo deploy:update
The same works from within a recipe, by simply setting the ROLES environment variable: env["ROLES"] = "foo" deploy.update Similarly, you can set HOSTS to execute only on specific hosts (even if the hosts aren't already defined in your deploy.rb file). Note that, in general, I discourage the use of this feature, because it is often misunderstood. It does not _restrict_ the execution of tasks to the given role, it _overrides_ the tasks to _all_ use the given role. Thus, even though deploy:migrate is restricted to the :db role, if you do "cap ROLES=foo deploy:migrations", it will run the migration on ALL :foo servers--a recipe for disaster. But, if you keep in mind that setting ROLES (or HOSTS) will execute all tasks on those roles, regardless of the tasks' original :roles settings, then you'll be fine. - Jamis On Jun 28, 2008, at 3:22 PM, Ian Sefferman wrote: > > Thinking about this a little bit more, it would work, but certainly > wouldn't make for the DRYest code. > > For example, I'd often like to use deploy:update, but have it > restricted to certain roles. Seems like I'd have to define a new > function which duplicates the standard cap deploy:update code... :( > > I could imagine something else like: > roles :foo, :bar do > deploy.update > end > > ...which would override any roles defined at the task definition level > and run it only on :foo, :bar. > > Thoughts? > Ian > > On Sat, Jun 28, 2008 at 8:14 AM, Ian Sefferman <[EMAIL PROTECTED]> > wrote: >> Ah, makes sense. Neat workaround. Thanks, Jamis! >> >> Ian >> >> On Sat, Jun 28, 2008 at 7:25 AM, Jamis Buck <[EMAIL PROTECTED]> >> wrote: >>> >>> If you declare it as a function, rather than a task, it'll use the >>> caller's scope, instead of its own scope. E.g.: >>> >>> def echo_bar >>> run "echo bar" >>> end >>> >>> task :foo, :roles => :foo do >>> run "echo foo" >>> echo_bar >>> end >>> >>> task :bar do >>> echo_bar >>> end >>> >>> Note that you can't do "cap echo_bar", because echo_bar is not a >>> task, >>> so I've kept the :bar task and had it just call the method. That >>> lets >>> you call "cap bar", just as before, and have it work as it did >>> before. >>> >>> - Jamis >>> >>> On Jun 28, 2008, at 12:12 AM, Ian Sefferman wrote: >>> >>>> >>>> Hi, >>>> I've noticed the following behavior: >>>> >>>> role :foo, "foo" >>>> role :bar, "bar" >>>> namespace :my_service do >>>> task :foo, :roles => :foo do >>>> run "echo \"foo\n\"" >>>> bar >>>> end >>>> >>>> task :bar do >>>> run "echo \"bar\n\"" >>>> end >>>> end >>>> >>>> If I run foo, bar will be ran for both the :foo and :bar role, >>>> which I >>>> wouldn't expect. I would expect that the task which is calling >>>> another >>>> task will be restricting the other task. >>>> >>>> I ask because one thing I'd like to do is have a few roles and have >>>> some, but not all, of the roles update their code >>>> (deploy.update), but >>>> currently this would always update it for all roles. >>>> >>>> Is there any workaround for this? Am I missing something obvious? >>>> >>>> Thanks, >>>> Ian >>>> >>>> >>>> -- >>>> Ian Sefferman >>>> http://www.openomy.com | http://www.iseff.com >>>> >>>>> >>> >>> >>>>> >>> >> >> >> >> -- >> Ian Sefferman >> http://www.openomy.com | http://www.iseff.com >> > > > > -- > Ian Sefferman > http://www.openomy.com | http://www.iseff.com > > > --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
