An alternative approach to #822 - this allows the setting of a single
`git_strategy` variable which can be set to `:archive` (the default, as
it is the current functionality) or `:clone` which includes the
`--recursive` flag in order to support submodules.
If an error is raised during a deploy, the task `deploy:failed` will be
triggered. Custom tasks can hook into this using `after`:
after 'deploy:failed', :send_for_help do
#
end
I've also taken the opportunity to provide a marginally more useful
error message before triggering the task.
By default, this 'deploy:failed' will only be triggered when running
`cap <stage> deploy` - to trigger after individual tasks use `set
:deploying, true`
This closes#708 and replaces
https://github.com/capistrano/capistrano/pull/720
This change allows both the `deploy_config_path` and `stage_config_path`
to be moved from the default locations of `config/deploy.rb` and
`config/deploy` respectively. These values __must__ be set in the
`Capfile` prior to `capistrano/setup` being called, for example:
set :deploy_config_path, 'app/config/deploy.rb'
set :stage_config_path, 'app/config/deploy'
# Load DSL and Setup Up Stages
require 'capistrano/setup'
Fixes#610
This commit removes the existing 'local' integration tests and replaces
them with Cucumber features running against VMs. At this stage,
some of the assertions are pending due to the limited nature of the
response returned when executing commands through Vagrant, but the
framework is there as a starting point to build upon.
To run the suite:
bundle exec cucumber
During development, avoid scraping the VM between runs:
bundle exec cucumber KEEPING_RUNNING=1
Ultimately I would like to see the `TestApp` helpers along with the Vagrant
integration packaged and available for use when developing gems that work with
Cap. For now though, this closes#641
