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.
The `upload!` method does escaping of its own internally, so we don't
need to do anything special there. Likewise environment variables are
already handled. The only place we need to explicitly `shellescape` is
when executing the `chmod` command.
Verify this all works as expected by changing the user in the Cucumber
features to be `(GitHub Web Flow) via ShipIt`. This user is now used
when exercising the `git:check` task.
Fixes#1842.
To accommodate Airbrussh, this commit makes the following changes:
1. Adds the airbrussh gem as a dependency
2. Bumps the sshkit dependency to 1.8.0 (for the new `use_format` method)
3. Introduces a `:format_options` setting
Out of the box, Capistrano now defaults to the following:
set :format, :airbussh
It also requires the airbrussh gem at the appropriate point in the Capistrano
boot process, which allows Airbrussh to register its `deploy:failed` hook.
We also change the default Airbrussh settings slightly, to acknowledge the fact
that Airbrussh will now be the first impression new Capistrano users have of the
tool.
Specifically:
* Enable command output (hiding the command output is tidy but probably will
confuse new users who will not know what their deploy script is doing)
* Disable the "using airbrussh format" banner at startup
Finally, this commit adds an official mechanism for sending a hash of options to
the formatter initializer. This lets users easily change Airbrussh's settings.
set :format_options, color: false, truncate: false, ...
If `:format_options` are set, Capistrano will send them to the formatter object
using SSHKit's `use_format` factory method. As of the latest SSHKit, all
formatters inheriting from `Formatter::Abstract` now accept an options hash
(although currently only Airbrussh does anything with them).
This removes the dependency on the `kuroko` gem and uses the Vagrant
command line application to control the virtual environment. The
`vagrant` command should be in your path, but if it isn't the path can
be set with the `VAGRANT_BIN` environment variable. This may even work
on older versions of Vagrant, but they are untested.
The `VagrantHelpers` module was added to mimic some of the API that was
provided by `kuroko`. The `RemoteCommandHelpers` module was modified to
accommodate those changes. Any non-zero exit status on a remote command
will raise a `VagrantHelpers::VagrantSSHCommandError` and should be
expected by any tests using the command helpers. All existing tests
work as expected.
In addition, a couple of minor changes were made. The TestApp utilizes
the Pathname library but does not require it. This was causing the suite
to fail for me so I added an explicit require. Also, the test for the
existence of a release directory would give a false positive on
subsequent runs if the `KEEP_RUNNING` option was used. I added an
`at_exit` that removes the test deployment directory to clean up the
box for the next run.
Documentation was also added to the README for how to run the test
suites.
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
The commit introduces a `remote_file` task, allowing the existence of a remote
file to be set as a prerequisite. These tasks can in turn depend on local
files if required. In this implementation, the fact that we're dealing with a
file in the shared path is assumed.
As as example, this task can be used to ensure that files to be linked exist
before running the `check:linked_files` task:
namespace :deploy do
namespace :check do
task :linked_files => 'config/newrelic.yml'
end
end
remote_file 'config/newrelic.yml' => '/tmp/newrelic.yml', roles: :app
file '/tmp/newrelic.yml' do |t|
sh "curl -o #{t.name} https://rpm.newrelic.com/accounts/xx/newrelic.yml"
end
This commit adds the outlines of a testing framework for Cap tasks.
Currently just the `cap install` and `cap deploy` tasks are covered. For
now, these tests can only be run if it is `ssh localhost` will work for
you and are currently excluded from the suite. It is my intention to
eventually replace the `sshkit` backend with a test backend, but for now
this is good enough to prevent simple regressions.
