`release_path` will now return the value of `current_path` by default.
Tasks that create a new release (i.e. `deploy`) now explicitly over-ride this
default with a new release path. This change allows tasks that run in both
deploy and non-deploy contexts to use `release_path` to target the latest
release when run in isolation, and the new release (before it is `current`)
when run as part of a deploy.
Ensure a Capistrano version by including a `lock` directive in your
Capfile:
lock '~> 3.0.0'
An error will be raised if the loaded version of Capistrano does not
meet the dependency specified.
Variables passed to the `server` or `role` syntax are correctly
assigned on the SSHKit::Host instance:
server 'example1.com', roles: %w{web app}, user: 'tomc', port: 2222
server 'example2.com', roles: %w{web app}, keys: '~/.ssh/key'
Expect this to close issue #384
Small modification, shows a proof of concept on how we can enable other
top-level command line flags by interacting with Rake (they could make this
easier, to be honest).
Two pending tests for a `--trace` option and a `--format` option, I'm not
fixed on these names, but the notion stands.
Support filtering of roles
# config/deploy/stage.rb
server 'example1.com', roles: %w{web app db}, active: :true
server 'example2.com', roles: %w{web app db}
on :app, filter: :active do
# do things on just example1.com
end
# config/deploy/stage.rb
server 'example1.com', roles: %w{web app db}, active: :true
server 'example2.com', roles: %w{web app db}
on :app, filter: { active: true } do
# do things on just example1.com
end
This patch makes it possible to do something like:
server 'example.com', some_property: true
on(:all, filter: :some_property) do |h|
# ...
end
This is the shorthand syntax which checks the host properties for anything
truthy matching the key name given. Symbols and strings are supported here.
If a more complex match should be made, then a continuation can be given in
the place of the smybol:
server 'example.com', some_property: true
on(:all, filter: lambda { |h| h.properties.some_property }) do |h|
# ...
end
The keys `filter` and `select` are aliases of one another. Either may be used
interchangably.
An execption is raised if the filter removes all matching servers.
Prior to this commit the "primary" server in each role was considered to be
the first one defined. This commit extends the behaviour of primary selection
to look to see if any of the hosts have the `primary` property set to a truthy
value.
In case that more than one server has a truthy `primary` property the first
one is taken as previously.
In order to set the primary property the extended `server()` syntax (that is
not `role()`) must be used, see b56206e.
This syntax allows servers to be specified long-hand including properties.
The `role(:my_role, %w{example.com, example.org})` is convenient for batch
set-up of servers; but as SSHKit provides arbirtary properties on servers, it
might be handy to set up servers in long hand:
server('example.com', roles: :my_role, my_property: "my_value")
server('example.com', roles: [:my_role, :another], my_property: "my_value")
server('example.com', roles: :my_role, primary: true)
This commit adds the ability to do this.
