capistrano 3.2.1 → 3.3.3

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 89a96214d20583f07f6f4094f94235893bec7ee1
-  data.tar.gz: 5744a684bea5aa5d11a400fb90159495e685c28f
+  metadata.gz: f5fec938fed98daad8d2ce764486a4b059095a1a
+  data.tar.gz: 5c46c098df29b9ea0f08a07db3270d83dcc598a3
 SHA512:
-  metadata.gz: e23596ce8fd844d9292f92a4fc7c6a97feceb85ecdfce82eb6462822ffe456929a693b4fdfeb2261258a7b8dffd65960c69e3688e4a433021e5db4e1062588a2
-  data.tar.gz: efc1d484e301975405fd1f7c3081ba0d2850e2dd8a64bcfbfc10b9f0b1dcbf1fea1e6e2e1cb07905327f984647c12ba798ad821198344fe9d30f8d1c291eeada
+  metadata.gz: ddfb0bdd5ea6266b25c6f96c02d466238f450ead5b4c47d13140c40db509ef92718dda37fefae01a364a812144d6cee16682be6ebfaa2274f1bdb558f218ff8f
+  data.tar.gz: f4e4fe76dacb08739437eaf3c83397f9119d8858ae23dff58b75c3325c380d0ca51cb995ebb26f00389aee9309a1eacad774bbf8c3da777c35640395715097b2

data/.travis.yml

@@ -3,8 +3,10 @@ rvm:
   - 2.1.0
   - 2.0.0
   - 1.9.3
-  - 1.9.2
-  - rbx
+  - rbx-2
 script: bundle exec rake spec
+install: bundle install --jobs=1
 cache: bundler
-bundler_args: --without cucumber
+branches:
+  except:
+    - legacy-v2

data/CHANGELOG.md

@@ -4,10 +4,98 @@ Reverse Chronological Order:
 
 ## master
 
-https://github.com/capistrano/capistrano/compare/v3.2.0...HEAD
+https://github.com/capistrano/capistrano/compare/v3.2.1...v3.3.0
+
+## `3.3.3`
+
+https://github.com/capistrano/capistrano/compare/v3.2.1...v3.3.0
+
+* Enhancement (@townsen)
+  * Added the variable `:repo_tree` which allows the specification of a sub-tree that
+    will be extracted from the repository. This is useful when deploying a project
+    that lives in a subdirectory of a larger repository.
+    Implemented only for git and hg.
+    If not defined then the behaviour is as previously and the whole repository is
+    extracted (subject to git-archive `.gitattributes` of course).
+
+* Enhancement (@townsen): Remove unnecessary entries from default backtrace
+
+    When the `--backtrace` (or `--trace`) command line option is not supplied
+    Rake lowers the noise level in exception backtraces by building
+    a regular expression containing all the system library paths and
+    using it to exclude backtrace entries that match.
+
+    This does not always go far enough, particularly in RVM environments when
+    many gem paths are added. This commit reverses that approach and _only_
+    include backtrace entries that fall within the Capfile and list of tasks
+    imported thereafter. This makes reading exceptions much easier on the eye.
+
+    If the full unexpurgated backtrace is required then the --backtrace
+    and --trace options supply it as before.
+
+* Disable loading stages configs on `cap -T`
+* Track (anonymous) statistics, see https://github.com/capistrano/stats
+
+* Enhancements (@townsen)
+  * Fix matching on hosts with custom ports or users set
+  * Previously filtering would affect any generated configuration files so that
+    files newly deployed would not be the same as those on the hosts previously
+    deployed (and now excluded by filters). This is almost certainly not what is
+    wanted: the filters should apply only to the on() method and thus any
+    configuration files deployed will be identical across the set of servers
+    making up the stage.
+  * Host and Role filtering now affects only `on()` commands
+    and not the `roles()`, `release_roles()` and `primary()` methods.
+  * This applies to filters defined via the command line, the environment
+    and the :filter variable.
+  * Filtering now supports Regular expressions
+  * This change _could_ cause existing scripts that use filtering and depend on
+    the old behaviour to fail, though it is unlikely. Users who rely on
+    filtering should check that generated configuration files are correct, and
+    where not introduce server properties to do the filtering. For example, if a
+    filter was used to specify an active subset of servers (by hostname), it should
+    be removed and replaced with an 'active' property (set to true or false) on the
+    server definitions. This keeps the stage file as the canonical model of the
+    deployment environment.
+
+  * See the documentation in the README.md file
+
+* Enhancements (@townsen)
+  * Added set_if_empty method to DSL to allow conditional setting
+  * Altered standard Capistrano defaults so that they are not set
+    at the start of a stage if they have been previously set. This
+    allows variables like :default_env to be set in deploy.rb.
+  * Deep copy properties added using the 'roles' keyword
+  * If a property exists on a server when another definition is
+    encountered and is an Array, Set or Hash then add the new values
+
+    This allows roles to specify properties common to all servers and
+    then for individual servers to modify them, keeping things DRY
+
+Breaking Changes:
+  * By using Ruby's noecho method introduced in Ruby version 1.9.3, we dropped support for Ruby versions prior to 1.9.3. See [issue #878](https://github.com/capistrano/capistrano/issues/878) and [PR #1112](https://github.com/capistrano/capistrano/pull/1112) for more information. (@kaikuchn)
+
+* Bug Fixes:
+  * Fixed compatibility with FreeBSD tar (@robbertkl)
+  * remote_file can be used inside a namespace (@mikz)
+
+* Minor Changes
+  * Remove -v flag from mkdir call. (@caligo-mentis)
+  * Capistrano now allows to customize `local_user` for revision log. (@sauliusgrigaitis)
+  * Added tests for after/before hooks features (@juanibiapina, @miry)
+  * Added `--force` flag to `svn export` command to fix errors when the release directory already exists.
+  * Improved the output of `cap --help`. (@mbrictson)
+  * Cucumber suite now runs on the latest version of Vagrant (@tpett)
+  * The `ask` method now supports the `echo: false` option. (@mbrictson, @kaikuchn)
+  * Cucumber scenario improvements (@bruno-)
+  * Added suggestion to Capfile to use 'capistrano-passenger' gem, replacing suggestion in config/deploy.rb to re-implement 'deploy:restart' (@betesh)
+  * Updated svn fetch_revision method to use `svnversion`
+  * `cap install` no longer overwrites existing files. (@dmarkow)
 
 ## `3.2.1`
 
+https://github.com/capistrano/capistrano/compare/v3.2.0...v3.2.1
+
 * Bug Fixes:
   * 3.2.0 introduced some behaviour to modify the way before/after hooks were called, to allow the optional
     preservation of arguments to be passed to tasks. This release reverts that commit in order to restore
@@ -19,6 +107,7 @@ https://github.com/capistrano/capistrano/compare/v3.2.0...HEAD
   * Changed asking question to more standard format (like common unix commandline tools) (@sponomarev)
   * Fixed typos in the README. (@sponomarev)
   * Added `keys` method to Configuration to allow introspection of configuration options. (@juanibiapina)
+  * Improve error message when git:check fails (raise instead of silently `exit 1`) (@mbrictson)
 
 ## `3.2.0`
 
@@ -40,7 +129,8 @@ https://github.com/capistrano/capistrano/compare/v3.0.1...v3.1.0
 Breaking changes:
 
   * `deploy:restart` task **is no longer run by default**.
-    From this version, developers who restart the app on each deploy need to declare it in their deploy flow (eg `after 'deploy:publishing', 'deploy:restart'`).
+    From this version, developers who restart the app on each deploy need to declare it in their deploy flow (eg `after 'deploy:publishing', 'deploy:restart'`)
+    or, for passenger applications, use the capistrano-passenger gem.
 
     Please, check https://github.com/capistrano/capistrano/commit/4e6523e1f50707499cf75eb53dce37a89528a9b0 for more information. (@kirs)
 

data/Gemfile

@@ -4,10 +4,6 @@ source 'https://rubygems.org'
 gemspec
 
 group :cucumber do
-  gem 'kuroko'
   gem 'cucumber'
-end
-
-platforms :rbx do
-  gem 'rubysl', '~> 2.0'
+  gem 'rspec', '~> 3.0.0'
 end

data/README.md

@@ -1,8 +1,8 @@
-# Capistrano [![Build Status](https://travis-ci.org/capistrano/capistrano.png?branch=v3)](https://travis-ci.org/capistrano/capistrano) [![Code Climate](https://codeclimate.com/github/capistrano/capistrano.png)](https://codeclimate.com/github/capistrano/capistrano) <a href="http://codersclan.net/?repo_id=325&source=small"><img src="http://www.codersclan.net/gs_button/?repo_id=325&size=small" width="69"></a>
+# Capistrano [![Build Status](https://travis-ci.org/capistrano/capistrano.svg?branch=master)](https://travis-ci.org/capistrano/capistrano) [![Code Climate](http://img.shields.io/codeclimate/github/capistrano/capistrano.svg)](https://codeclimate.com/github/capistrano/capistrano) <a href="http://codersclan.net/?repo_id=325&source=small"><img src="http://img.shields.io/badge/get-support-blue.svg"></a>
 
 ## Requirements
 
-* Ruby >= 1.9 (JRuby and C-Ruby/YARV are supported)
+* Ruby >= 1.9.3 (JRuby and C-Ruby/YARV are supported)
 
 ## Support
 
@@ -55,7 +55,7 @@ $ bundle exec cap install STAGES=local,sandbox,qa,production
 ## Usage
 
 ``` sh
-$ bundle exec cap -vT
+$ bundle exec cap -T
 
 $ bundle exec cap staging deploy
 $ bundle exec cap production deploy
@@ -153,6 +153,11 @@ end
 
 Perfect, who needs telephones.
 
+When using `ask` to get user input, you can pass `echo: false` to prevent the input from being displayed:
+
+```ruby
+ask(:database_password, "default", echo: false)
+```
 
 ## Using password authentication
 
@@ -224,6 +229,13 @@ DEBUG [9ce34809]  leehambley pts/0        2013-06-13 17:11 (port-11262.pppoe.wtn
  INFO [9ce34809] Finished in 0.420 seconds command successful.
 ```
 
+## VCS Requirements
+
+Capistano requires modern versions of Git, Mercurial and Subversion
+respectively (if you are using that particular VCS). Git Git requirement is at
+least version 1.8.x. Mercurial and Subversion, any modern version should
+suffice.
+
 ## A word about PTYs
 
 There is a configuration option which asks the backend driver to ask the remote host
@@ -252,6 +264,7 @@ The following variables are settable:
 | Variable Name         | Description                                                          | Notes                                                           |
 |:---------------------:|----------------------------------------------------------------------|-----------------------------------------------------------------|
 | `:repo_url`           | The URL of your scm repository (git, hg, svn)                        | file://, https://, ssh://, or svn+ssh:// are all supported      |
+| `:repo_tree`          | The subtree of the scm repository to deploy (git, hg)                | Only implemented for git and hg repos. Extract just this tree   |
 | `:branch`             | The branch you wish to deploy                                        | This only has meaning for git and hg repos, to specify the branch of an svn repo, set `:repo_url` to the branch location. |
 | `:scm`                | The source control system used                                       | `:git`, `:hg`, `:svn` are currently supported                   |
 | `:tmp_dir`            | The (optional) temp directory that will be used (default: /tmp)      | if you have a shared web host, this setting may need to be set (i.e. /home/user/tmp/capistrano). |
@@ -262,6 +275,53 @@ __Support removed__ for following variables:
 |:---------------------:|---------------------------------------------------------------------|-----------------------------------------------------------------|
 | `:copy_exclude`       | The (optional) array of files and/or folders excluded from deploy | Replaced by Git's native `.gitattributes`, see [#515](https://github.com/capistrano/capistrano/issues/515) for more info. |
 
+## Host and Role Filtering
+
+Capistrano enables the declaration of servers and roles, each of which may have properties
+associated with them.  Tasks are then able to use these definitions in two distinct ways:
+
+* To determine _configurations_: typically by using the `roles()`, `release_roles()` and
+  `primary()` methods. Typically these are used outside the scope of the `on()` method.
+
+* To _interact_ with remote hosts using the `on()` method
+
+An example of the two would be to create a `/etc/krb5.conf` file containing the list of
+available KDC's by using the list of servers returned by `roles(:kdc)` and then uploading
+it to all client machines using `on(roles(:all)) do upload!(file) end`
+
+A problem with this arises when _filters_ are used. Filters are designed to limit the
+actual set of hosts that are used to a subset of those in the overall stage, but how
+should that apply in the above case?
+
+If the filter applies to both the _interaction_ and _configuration_ aspects, any configuration
+files deployed will not be the same as those on the hosts excluded by the filters. This is
+almost certainly not what is wanted, the filters should apply only to the _interactions_
+ensuring that any configuration files deployed will be identical across the stage.
+
+Another type of filtering is done by defining properties on servers and selecting on that
+basis. An example of that is the 'no_release' property and it's use in the
+`release_roles()` method. To distinguish these two types of filtering we name them:
+
+* On-Filtering
+    Specified in the following ways:
+    * Via environment variables HOSTS and ROLES
+    * Via command line options `--hosts` and `--roles`
+    * Via the `:filter` variable set in a stage file
+* Property-Filtering
+    These are specified by options passed to the `roles()` method (and implicitly in methods
+    like `release_roles()` and `primary()`)
+
+To increase the utility of On-Filters they can use regular expressions:
+* If the host name in a filter doesn't match `/^[-A-Za-z0-9.]+$/` (the set of valid characters
+    for a DNS name) then it's assumed to be a regular expression.
+* Since role names are Ruby symbols they can legitimately contain any characters. To allow multiple
+    of them to be specified on one line we use the comma. To use a regexp for a role filter begin
+    and end the string with '/'. These may not contain a comma.
+
+When filters are specified using comma separated lists, the final filter is the _union_ of
+all of the components. However when multiple filters are declared the result is the
+_intersection_.
+
 ## SSHKit
 
 [SSHKit](https://github.com/leehambley/sshkit) is the driver for SSH
@@ -269,6 +329,27 @@ connections behind the scenes in Capistrano. Depending on how deep you dig, you
 might run into interfaces that come directly from SSHKit (the configuration is
 a good example).
 
+## Testing
+
+Capistrano has two test suites: an RSpec suite and a Cucumber suite. The
+RSpec suite handles quick feedback unit specs. The Cucumber features are
+an integration suite that uses Vagrant to deploy to a real virtual
+server. In order to run the Cucumber suite you will need to install
+[Vagrant](http://www.vagrantup.com/) and Vagrant supported
+virtualization software like
+[VirtualBox](https://www.virtualbox.org/wiki/Downloads).
+
+```
+# To run the RSpec suite
+$ rake spec
+
+# To run the Cucumber suite
+$ rake features
+
+# To run the Cucumber suite and leave the VM running (faster for subsequent runs)
+$ rake features KEEP_RUNNING=1
+```
+
 ## License
 
 MIT License (MIT)

data/Rakefile

@@ -1,5 +1,9 @@
 require "bundler/gem_tasks"
+require "cucumber/rake/task"
+require "rspec/core/rake_task"
 
 task :default => :spec
-require 'rspec/core/rake_task'
 RSpec::Core::RakeTask.new
+
+Cucumber::Rake::Task.new(:features)
+

data/capistrano.gemspec

@@ -20,12 +20,16 @@ Gem::Specification.new do |gem|
   gem.licenses      = ['MIT']
 
   gem.post_install_message = <<eos
-Capistrano 3.1 has some breaking changes, like `deploy:restart` callback should be added manually to your deploy.rb. Please, check the CHANGELOG: http://goo.gl/SxB0lr
+Capistrano 3.1 has some breaking changes. Please check the CHANGELOG: http://goo.gl/SxB0lr
 
 If you're upgrading Capistrano from 2.x, we recommend to read the upgrade guide: http://goo.gl/4536kB
+
+The `deploy:restart` hook for passenger applications is now in a separate gem called capistrano-passenger.  Just add it to your Gemfile and require it in your Capfile.
 eos
 
+  gem.required_ruby_version = '>= 1.9.3'
   gem.add_dependency 'sshkit', '~> 1.3'
+  gem.add_dependency 'capistrano-stats', '~> 1.0.3'
   gem.add_dependency 'rake', '>= 10.0.0'
   gem.add_dependency 'i18n'
 

data/features/configuration.feature

@@ -19,10 +19,12 @@ Feature: The path to the configuration can be changed, removing the need to
     Then the task is successful
     And contains "install" in the output
 
-  Scenario: Show install task with configuration in a custom location
-    And config stage file has line "desc 'Special Task'"
-    And config stage file has line "task :special_stage_task"
-    But the configuration is in a custom location
-    When I run "cap -T"
-    Then the task is successful
-    And contains "special_stage_task" in the output
+  # Feature disabled because this is not how it works, we don't load
+  # tasks from stage files, as we expect them to be defined in ./lib/tasks
+  # Scenario: Show install task with configuration in a custom location
+  #   And config stage file has line "desc 'Special Task'"
+  #   And config stage file has line "task :special_stage_task"
+  #   But the configuration is in a custom location
+  #   When I run "cap -T"
+  #   Then the task is successful
+  #   And contains "special_stage_task" in the output

data/features/deploy.feature

@@ -6,7 +6,8 @@ Feature: Deploy
 
   Scenario: Creating the repo
     When I run cap "git:check"
-    Then references in the remote repo are listed
+    Then the task is successful
+    And references in the remote repo are listed
 
   Scenario: Creating the directory structure
     When I run cap "deploy:check:directories"
@@ -22,16 +23,16 @@ Feature: Deploy
     Then directories referenced in :linked_files are created in shared
 
   Scenario: Checking linked files - missing file
-    Given a required file
-    But the file does not exist
+    Given a linked file "missing_file.txt"
+    But file "missing_file.txt" does not exist in shared path
     When I run cap "deploy:check:linked_files"
-    Then the task will exit
+    Then the task fails
 
   Scenario: Checking linked files - file exists
-    Given a required file
-    And that file exists
+    Given a linked file "existing_file.txt"
+    And file "existing_file.txt" exists in shared path
     When I run cap "deploy:check:linked_files"
-    Then the task will be successful
+    Then the task is successful
 
   Scenario: Creating a release
     Given I run cap "deploy:check:directories"
@@ -40,7 +41,7 @@ Feature: Deploy
     And the release is created
 
   Scenario: Symlink linked files
-    When I run cap "deploy:symlink:linked_files" as part of a release
+    When I run cap "deploy:symlink:linked_files deploy:symlink:release" as part of a release
     Then file symlinks are created in the new release
 
   Scenario: Symlink linked dirs

data/features/step_definitions/assertions.rb

@@ -1,4 +1,5 @@
 Then(/^references in the remote repo are listed$/) do
+  expect(@output).to include('refs/heads/master')
 end
 
 Then(/^the shared path is created$/) do
@@ -22,13 +23,6 @@ Then(/^directories referenced in :linked_files are created in shared$/) do
   end
 end
 
-Then(/^the task will be successful$/) do
-end
-
-
-Then(/^the task will exit$/) do
-end
-
 Then(/^the repo is cloned$/) do
   run_vagrant_command(test_dir_exists(TestApp.repo_path))
 end
@@ -38,9 +32,8 @@ Then(/^the release is created$/) do
 end
 
 Then(/^file symlinks are created in the new release$/) do
-  pending
   TestApp.linked_files.each do |file|
-    run_vagrant_command(test_symlink_exists(TestApp.release_path.join(file)))
+    run_vagrant_command(test_symlink_exists(TestApp.current_path.join(file)))
   end
 end
 
@@ -57,26 +50,26 @@ end
 
 Then(/^the deploy\.rb file is created$/) do
   file = TestApp.test_app_path.join('config/deploy.rb')
-  expect(File.exists?(file)).to be_true
+  expect(File.exists?(file)).to be true
 end
 
 Then(/^the default stage files are created$/) do
   staging = TestApp.test_app_path.join('config/deploy/staging.rb')
   production = TestApp.test_app_path.join('config/deploy/production.rb')
-  expect(File.exists?(staging)).to be_true
-  expect(File.exists?(production)).to be_true
+  expect(File.exists?(staging)).to be true
+  expect(File.exists?(production)).to be true
 end
 
 Then(/^the tasks folder is created$/) do
   path = TestApp.test_app_path.join('lib/capistrano/tasks')
-  expect(Dir.exists?(path)).to be_true
+  expect(Dir.exists?(path)).to be true
 end
 
 Then(/^the specified stage files are created$/) do
   qa = TestApp.test_app_path.join('config/deploy/qa.rb')
   production = TestApp.test_app_path.join('config/deploy/production.rb')
-  expect(File.exists?(qa)).to be_true
-  expect(File.exists?(production)).to be_true
+  expect(File.exists?(qa)).to be true
+  expect(File.exists?(production)).to be true
 end
 
 Then(/^it creates the file with the remote_task prerequisite$/) do
@@ -90,7 +83,11 @@ Then(/^it will not recreate the file$/) do
 end
 
 Then(/^the task is successful$/) do
-  expect(@success).to be_true
+  expect(@success).to be true
+end
+
+Then(/^the task fails$/) do
+  expect(@success).to be_falsey
 end
 
 Then(/^the failure task will run$/) do
@@ -100,7 +97,8 @@ end
 
 Then(/^the failure task will not run$/) do
   failed = TestApp.shared_path.join('failed')
-  !run_vagrant_command(test_file_exists(failed))
+  expect { run_vagrant_command(test_file_exists(failed)) }
+    .to raise_error(VagrantHelpers::VagrantSSHCommandError)
 end
 
 When(/^an error is raised$/) do