My monkeypatch is here: https://github.com/donnoman/cap-recipes/blob/master/lib/cap_recipes/tasks/provision/empty_roles.rb
No per task configuration required. On Jul 31, 2012, at 8:46 AM, Jonathan Rochkind <[email protected]> wrote: > Sorry, I missed the beginning of the thread, but is the problem that cap is > raising an error for an empty role? > > This is under-documented, but is changeable. I use sometimes-empty roles too, > for the same reasons Donovan says, I agree it is a quite useful and not > unique use case. > > To make it work, every task assigned to that role that might be empty, I need > to do this: > > task :some_task, :roles => :might_be_empty, :on_no_matching_servers => > :continue > > It is annoying, and I agree that this empty roles are VERY convenient for > exactly the reasons Donovan says.... but it is POSSIBLE, you've just got to > do that :on_no_matching_servers => :continue on every task that might be in > an empty role. > > On 7/31/2012 11:25 AM, Donovan Bray wrote: >> I disagree. I specifically monkey patch cap to allow this behavior. >> >> In some stages I need a front end nginx loadbalancer and some cases I >> don't because I'm either using Zeus or an ELB. I can use Role targeting >> in my stage files by either including a nginx role or omit it, and a cap >> deploy will do the right thing in all three cases and all I had to do >> was manipulate the role assignments on the server objects. >> >> Once you embrace the concept that roles can be empty it opens up a whole >> new level of flexibility for stage definition. >> >> I think it's an artificial constraint that has no pros. >> >> If you don't like empty roles don't define them. If you inadvertently >> don't populate a role you'll figure it out in short order without cap >> raising an exception. >> >> >> On Jul 31, 2012, at 1:40 AM, Lee Hambley <[email protected] >> <mailto:[email protected]>> wrote: >> >>> The documentation is almost certainly wrong, there's been a lot of >>> changes to this code from various patches since the docs were written. >>> Unfortunately being in a Wiki we can't take documentation patches >>> along with code patches in the pull requests, and people often forget >>> to update the docs once we mere their pull request. Perhaps you'd like >>> to update them to reflect the current behavior? >>> >>> (I can't see a case for running a task with an empty list of servers >>> for a role, Capistrano is a tool for working on remote hosts, if you >>> have a task that doesn't have remote hosts, it's probably a rake task) >>> >>> Cheers, Lee >>> >>> -- >>> * You received this message because you are subscribed to the Google >>> Groups "Capistrano" group. >>> * To post to this group, send email to [email protected] >>> <mailto:[email protected]> >>> * To unsubscribe from this group, send email to >>> [email protected] >>> <mailto:[email protected]> For more options, >>> visit this group at http://groups.google.com/group/capistrano?hl=en >> >> -- >> * You received this message because you are subscribed to the Google >> Groups "Capistrano" group. >> * To post to this group, send email to [email protected] >> * To unsubscribe from this group, send email to >> [email protected] For more options, visit this >> group at http://groups.google.com/group/capistrano?hl=en > > -- > * You received this message because you are subscribed to the Google Groups > "Capistrano" group. > * To post to this group, send email to [email protected] > * To unsubscribe from this group, send email to > [email protected] For more options, visit this group at > http://groups.google.com/group/capistrano?hl=en -- * You received this message because you are subscribed to the Google Groups "Capistrano" group. * To post to this group, send email to [email protected] * To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/capistrano?hl=en
