I've taken the responsibility for executing scm commands away from the
rake tasks and have placed them in an SCM object. This object can be
loaded with any given strategy.
A default strategy is supplied (the commands as they where in the rake
tasks)
Moved Hg to the new strategy pattern
This commit adds the ability to control what servers are involved in an
task from the command line, or by setting an environment variable.
The filter contains a list of servers; these are the only servers that
will be involved in the task.
For example, if you had three servers defined in your configuration
(server1, server2 and server3), you could deploy to only server1 by
doing either:
cap --hosts server1 production deploy
Or:
HOSTS=server1 cap production deploy
Multiple servers can be specified by separating them with commas:
cap --hosts server1,server2 production deploy
HOSTS=server1,server2 cap production deploy
Host filtering happens after role filtering, and does not change what
roles a server will respond to.
For the case where the array may be stored in a variable, for example:
set :my_roles, [:app, :web]
on roles fetch(:my_roles) do
#
end
This will allow https://github.com/capistrano/rails/pull/30 to be
refactored
The functionality to filter the executing tasks by role (i.e. deploying
only to servers that match the role you specify) already exists. It can
specified either by using the following in your deployment config:
set :filter, :roles => %w{app web}
Or by setting `ENV['ROLES']`:
ROLES=app,web cap production deploy
This commit adds a command line switch to set the role filter, which
avoids polluting ENV:
cap --roles=app,web production deploy
When deploying to multiple different roles, symlinks currently only
happen on the app role. When you then try and precompile assets on the
web role for example, the symlinks that it requires to link to certain
config files may not be there. This fix changes the default symlink
behaviour to happen on _all_ roles as this seems like a more sensible
default.
