Yes, that's exactly what I was looking for. Having dug deeper into
things, it's become obvious that I misunderstood the purpose of the
ROLES environment variable. In fact, to me it seem contradictory to
the :roles task attribute. It seems (someone please correct me if I'm
wrong) that the environment variable exists to override things such
that tasks that would ordinarily be restricted are executed on, rather
than (as I understood it) to mean "only run the tasks that are
applicable for the roles I'm giving you". I'm not sure if the
existing behavior is really all that useful, but definitely find the
latter behavior useful, so would certainly lobby for behavior like
that which your patch provides to be included in the mainstream
capistrano, or at minimum in capistrano-ext.
Thanks for putting this patch together, it's exactly what I needed!
Dan
On Oct 5, 12:50 pm, Stevie Clifton <[EMAIL PROTECTED]> wrote:
> Hi Dan,
>
> I had a very similar need, and I'll post the code (hack?) below that
> helped me get what I wanted. The way the ROLES variable works never
> made intuitive sense to me. Instead of overriding what roles are
> specified for a given task, my feeling is that it should just run the
> tasks/subtasks that specify that role and ignore the others. I've
> never had a situation where the current implementation of the ROLES
> variables has helped as almost all my tasks have subtasks.
>
> So I made simple modifications to both the run method and the
> find_servers method. Now that I think about it, this will probably
> have problems on sub-sub-tasks, but it's worked great for what I've
> needed as I usually only specify a :roles => XXX for a task that comes
> at the bottom of the execution chain. Now that I'm filtering out any
> tasks that are not specified for the current ROLESFILTER, it's
> probable that there will be tasks that try to execute but have all
> their servers "filtered" out. So you need to catch any
> "NoMatchingServersError" in the run method to prevent cap from dying.
>
> # allow a ROLESFILTER to be passed which only executes tasks that
> already specify that role
> module Capistrano::Configuration::Servers
> alias_method :old_find_servers, :find_servers
> def find_servers(*args)
> servers = old_find_servers(*args)
> if ENV['ROLESFILTER']
> filtered_roles = role_list_from(ENV['ROLESFILTER'])
> filtered_roles_servers = roles.inject([]) { |list, role|
> list.concat(self.roles[role]) }
> end
> servers = servers & filtered_roles_servers
> end
> end
>
> # Now doesn't die if can't find a server for the role
> module Capistrano::Configuration::Actions::Invocation
> alias_method :old_run, :run
> def run(*args)
> begin
> old_run(*args)
> rescue Capistrano::NoMatchingServersError => error
> puts " ** Skipped task"
> end
> end
> end
>
> HTH.
>
> stevie
>
> On 4 Oct, 14:42, Dan Powell <[EMAIL PROTECTED]> wrote:> It's actually the
> ROLES variable I'm trying to set. Basically, my
> > application (not a Rails application) has a few tiers that each have
> > different deployment needs. For example, the directories from
> > shared_path that I need to link into latest_release vary somewhat. To
> > accomplish this, I tried creating a symlink_tiera and symlink_tierb
> > task each called by the symlink task. This works fine when I'm
> > running the deploy (or symlink directly) task with no ROLES
> > restrictions - it runs the symlink_tiera instructions only on the
> > tiera hosts and the symlink_tierb instructions only on the tierb
> > hosts. However, if I specify ROLES=tiera when I run cap, it runs the
> > instructions for tiera and tierb on the tiera hosts, and nothing on
> > the tierb hosts. The desired behavior would be for it to run only the
> > tiera instructions and only on the tiera hosts, and not run any of the
> > tierb instructions anywhere and do nothing with the tierb hosts.
>
> > Is there any reason that subtasks should not observe the role
> > declarations specified in the environment? It seems like if a task is
> > set to only run on certain roles you would never want it to run on
> > hosts of a different role, and that that task should simply be
> > skipped. This particularly seems inconsistent with the behavior I
> > observe when I don't specify a ROLES environment variable - why would
> > it not observe the role declarations in this case but not when I
> > specify a ROLES list?
>
> > I suppose a concrete example might be if I am using a ferret DRb on a
> > separate box, I might want my stop and start tasks to run the
> > appropriate commands on a ferret role while still running the usual
> > mongrel commands on the app role. I would never want to run the
> > stop_ferret task on the app role, nor to run the start_mongrel task on
> > the ferret role.
>
> > On Oct 4, 1:09 pm, Jamis Buck <[EMAIL PROTECTED]> wrote:
>
> > > Specifying either ROLES or HOSTS will use the given roles or hosts
> > > for all tasks that are executed, basically overriding whatever roles/
> > > hosts declarations any tasks have. This is mostly only useful for
> > > simple tasks, which do not themselves invoke other tasks, and was
> > > intended originally to make it possible to do things like
> > > deploy:setup on only a subset of your servers.
>
> > > I'm open to suggestions about how to make this more useful. Dan, can
> > > you tell me more of what you're trying to do with the HOSTS
> > > environment variable, and what the behavior you expect is?
>
> > > - Jamis
>
> > > On Oct 4, 2007, at 10:32 AM, Dan Powell wrote:
>
> > > > I can see how that might help with HOST restrictions where you want to
> > > > change hosts in the middle, but here my restrictions are role based
> > > > and the hosts for those roles are not changing at runtime.
>
> > > > Based on Jamis' comment in that thread "If you set the HOSTS
> > > > environment variable, all tasks will use it,
> > > > instead of whatever hosts list they might have otherwise. " I even
> > > > tried explicitly hard coding setting the ROLES variable, but that
> > > > didn't really help anything. Perhaps that's a HOSTS vs ROLES
> > > > behavior, I'm not sure. Should I try to set the HOSTS variable with
> > > > the hosts for the ROLES I've specified? Again, I'm not changing HOSTS
> > > > (or ROLES) in midstream, so I'm not sure why "changing" these
> > > > variables to the same value as the one specified when invoking cap
> > > > would help, unless there is some destructive processing done to the
> > > > ROLES set on startup that I'm now having to override in my task.
>
> > > > On Oct 4, 9:54 am, Joe <[EMAIL PROTECTED]> wrote:
> > > >> Dan,
>
> > > >> Seehttp://groups.google.com/group/capistrano/browse_thread/
> > > >> thread/c4885d....
>
> > > >> Joe
>
> > > smime.p7s
> > > 3KDownload
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
