I coded a solution for this, and comments on the problem are at this url:

https://gist.github.com/251078


On Fri, Jul 8, 2011 at 8:44 AM, Peter <[email protected]> wrote:

> Hi,
>
> I have what I think is a common deploy setup with an app and
> background server and i'm having a problem with a multistage
> deployment that tries to omit a role.  Let me give some specifics.  I
> have the following items in my deploy.rb:
>
> namespace :background do
>  task :start, :roles => :background do
>    ...
>  end
>  task :stop, :roles => :background do
>    ...
>  end
>  before "deploy:restart", "deploy:background:stop"
>  after "deploy:restart", "deploy:background:start"
>
>  after "deploy:stop", "deploy:background:stop"
>  after "deploy:start","deploy:background:start"
> end
>
> The idea here is that the background server should start and stop in
> response to deploy's restart, stop and start.  However, if I have a
> role file that doesn't have a background role (i.e. some test or demo
> environment where I don't want it) these commands don't work as I'd
> expect:
>
> cap deploy:restart
>  Expected - should restart the app server, skip the background server
> since none are found
>  Actual - bails on the before "deploy:restart" due to no servers
> found with role :background; stops the app restart from actually
> occuring
>
> cap deploy:restart ROLES=app
>  Expected - should restart the app server, skip the background server
> since no tasks match it
>  Actual - runs the background stop and start tasks on the app server
>
> In short, its like once something is added to a before or after
> callback it ignores the purpose of the :roles option set on it, which
> is only to run it in that scenario.  It seems in both cases it should
> be smart enough to say hey, this is a background role task and i
> either have no background servers or i am running with ROLES that
> omits it, so it should be skipped.
>
> My two questions are whether this is a bug or if I'm doing something
> non-standard; and either way what are the suggested workarounds for
> this?
>
> Thanks,
> \Peter
>
> --
> * 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

Reply via email to