Much like rake can find its Rakefile even when run in a subdirectory,
cap can now find its Capfile. Since cap is built on top of rake, this
was really just restoring default behavior that was accidentally
overridden.
Also add a feature test to ensure it works.
Capistrano 'git:check' task executes a `git ls-remote -h #{repo_url}`
command to check if remote repo is accessible. If successful, command
output is a list of references and their SHAs.
Task should be successful and we're pretty sure remote repo will have a
`master` reference, so that's what we're asserting.
We're NOT asserting:
* repo references other than master - likely to change
* reference SHAs - will definitely change
To show all tasks decalred in default config and stages files was missed from the tasks list.
Added default value for :stage and load all default configs. Also added cucumber tests.
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
