capistrano 3.4.1 → 3.5.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 69ec5d772357af1d69b41f723ae4e21cdd4da62f
-  data.tar.gz: c5fbbbc5d594f7959d836144fa31cfbf671df610
+  metadata.gz: 997bdc47eec05054270bbd80c9d5e44fb142c7ad
+  data.tar.gz: 82ae85408f7e67427b2cffccc95c2fe33c834288
 SHA512:
-  metadata.gz: ab6ff6ef7b481d3268b44b0b5e63c683888501471bd4b1bd45a9881067bcb0c606245b3eeb8522ec184b632179811ad5507e3a82eecf51634251a23596e7d9fe
-  data.tar.gz: 85907284c746b0e35478d6cd725faea3d9b1c3724821ea2d3159979c1d09a46bbcd7a7e917667a4fa79411e73147f54e45c06e692686d1f7a2b1e78a6370b390
+  metadata.gz: 3a3314345dc42f3eb9c26c9eb249bf20281d4e57944c19b7e04f97597daac149a858c5eddda45958b9304323d3fa36722d845699c704345724993d100efd3117
+  data.tar.gz: b16b26b8b29ea8a82bbd61850595807f9a045f7d3a3fb66330ce7fb4b00fd6775747a482a1eb3cec3c1ecdb9604487fe7b509f1884d23d39fbe1464a2399d0ad

data/.gitignore

@@ -1,10 +1,15 @@
 *.gem
 *.rbc
+*.swp
 .bundle
 .config
+.rspec
+.rspec-local
+.ruby-version
 .yardoc
 Gemfile.lock
 InstalledFiles
+_site
 _yardoc
 coverage
 doc/
@@ -12,11 +17,8 @@ lib/bundler/man
 pkg
 rdoc
 spec/reports
+tags
 test/tmp
 test/version_tmp
 tmp
-.rspec-local
-.ruby-version
-_site
-.rspec
-*.swp
+vendor/

data/.rubocop.yml

@@ -0,0 +1,49 @@
+AllCops:
+  DisplayCopNames: true
+  DisplayStyleGuide: true
+  TargetRubyVersion: 2.0
+
+Style/BarePercentLiterals:
+  EnforcedStyle: percent_q
+Style/ClassAndModuleChildren:
+  Enabled: false
+Style/DoubleNegation:
+  Enabled: false
+Style/SpaceAroundEqualsInParameterDefault:
+  EnforcedStyle: no_space
+Style/StringLiterals:
+  EnforcedStyle: double_quotes
+Style/TrivialAccessors:
+  AllowPredicates: true
+Style/PercentLiteralDelimiters:
+  Enabled: false
+Style/SingleLineBlockParams:
+  Enabled: false
+Style/ModuleFunction:
+  Enabled: false
+
+# Enable someday
+Style/Documentation:
+  Enabled: false
+
+# Needs refactors
+Metrics/PerceivedComplexity:
+  Enabled: false
+Metrics/CyclomaticComplexity:
+  Enabled: false
+Metrics/MethodLength:
+  Enabled: false
+Style/PredicateName:
+  Enabled: false
+Metrics/LineLength:
+  Enabled: false
+Metrics/AbcSize:
+  Enabled: false
+Style/PerlBackrefs:
+  Enabled: false
+Metrics/ClassLength:
+  Enabled: false
+Metrics/ModuleLength:
+  Enabled: false
+Style/AccessorMethodName:
+  Enabled: false

data/.travis.yml

@@ -1,10 +1,11 @@
 language: ruby
 rvm:
-  - 2.1.0
-  - 2.0.0
-  - 1.9.3
+  - 2.3.0
+  - 2.2
+  - 2.1
+  - 2.0
   - rbx-2
-script: bundle exec rake spec
+script: bundle exec rake spec rubocop
 install: bundle install --jobs=1
 cache: bundler
 branches:

data/CHANGELOG.md

@@ -4,14 +4,71 @@ Reverse Chronological Order:
 
 ## master
 
-https://github.com/capistrano/capistrano/compare/v3.4.1...HEAD
-
-## `3.4.1`
-
-https://github.com/capistrano/capistrano/compare/v3.4.0...v3.4.1
-
-* Fix compatibility with Rake 11.0 (backported from
-  https://github.com/capistrano/capistrano/pull/1631) (@leehambley)
+https://github.com/capistrano/capistrano/compare/v3.5.0...HEAD
+
+## `3.5.0`
+
+https://github.com/capistrano/capistrano/compare/v3.4.1...v3.5.0
+
+**You'll notice a big cosmetic change in this release: the default logging
+format has been changed to
+[Airbrussh](https://github.com/mattbrictson/airbrussh).** For more details on
+what Airbrussh does
+and how to configure it, visit the
+[Airbrussh README](https://github.com/mattbrictson/airbrussh#readme).
+
+* To opt out of the new format, simply add `set :format, :pretty` to switch to
+  the old default of Capistrano 3.4.0 and earlier.
+* If you are already an Airbrussh user, note that the default configuration has
+  changed, and the syntax for configuring Airbrussh has changed as well.
+  [This simple upgrade guide](https://github.com/mattbrictson/airbrussh/blob/master/UPGRADING-CAP-3.5.md)
+  will walk you through it.
+
+### Potentially breaking changes:
+
+* Drop support for Ruby 1.9.3 (Capistrano may still work with 1.9.3, but it is
+  no longer officially supported)
+* Git version 1.6.3 or greater is now required
+* Remove 'vendor/bundle' from default :linked_dirs (@ojab)
+* Old versions of SSHKit (before 1.9.0) are no longer supported
+* SHA1 hash of current git revision written to REVISION file is no longer abbreviated
+
+### New features:
+
+* Added a `doctor` task that outputs helpful troubleshooting information. Try it like this: `cap production doctor`. (@mattbrictson)
+* Added a `dry_run?` helper method
+* `remove` DSL method for removing values like from arrays like `linked_dirs`
+* `append` DSL method for pushing values like `linked_dirs`
+  [#1447](https://github.com/capistrano/capistrano/pull/1447),
+  [#1586](https://github.com/capistrano/capistrano/pull/1586)
+* Added support for git shallow clone
+* Added new runtime option `--print-config-variables` that inspect all defined config variables in order to assist development of new capistrano tasks (@gerardo-navarro)
+* Prune dead tracking branches from git repositories while updating
+* Added options to set username and password when using Subversion as SCM (@dsthode)
+* Allow after() to refer to tasks that have not been loaded yet (@jcoglan)
+* Allow use "all" as string for server filtering (@theist)
+* Print a warning and abort if "load:defaults" is erroneously invoked after
+  capistrano is already loaded, e.g. when a plugin is loaded in `deploy.rb`
+  instead of `Capfile`. (@mattbrictson)
+* Added option to set specific revision when using Subversion as SCM (@marcovtwout)
+* Deduplicate list of linked directories
+* Integration with Harrow.io (See http://capistranorb.com/documentation/harrow/) when running `cap install`
+
+### Fixes:
+
+* Capistrano is now fully-compatible with Rake 11.0. (@mattbrictson)
+* Fix filtering behaviour when using literal hostnames in on() block (@townsen)
+* Allow dot in :application name (@marcovtwout)
+* Fixed git-ssh permission error (@spight)
+
+### Other changes:
+
+* Internal Rubocop cleanups.
+* Removed the post-install message (@Kriechi)
+* Refactor `Configuration::Filter` to use filtering strategies instead
+  of case statements (@cshaffer)
+* Clean up rubocop lint warnings (@cshaffer)
+* Ensure task invocation within after hooks is namespace aware (@thickpaddy)
 
 ## `3.4.0`
 
@@ -32,7 +89,7 @@ https://github.com/capistrano/capistrano/compare/v3.3.5...v3.4.0
 * Breaking Changes
   * Hosts with the same name are now consolidated into one irrespective of the
     user and port. This allows multiple declarations of a server to be made safely.
-    The last declared properties will win. See capistrnorb.com Properties documentation
+    The last declared properties will win. See capistranorb.com Properties documentation
     for details.
   * Inside the on() block the host variable is now a copy of the host, so changes can be
     made within the block (such as dynamically overriding the user) that will not persist.
@@ -130,6 +187,12 @@ https://github.com/capistrano/capistrano/compare/v3.2.1...v3.3.3
     This allows roles to specify properties common to all servers and
     then for individual servers to modify them, keeping things DRY
 
+* Enhancements (@Kriechi)
+  * Added validate method to DSL to allow validation of certain values
+    - validate values before assignment inside of `set(:key, value)`
+    - should raise a `Capistrano::ValidationError` if invalid
+  * Added default validation for Capistrano-specific variables
+
 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)
   * Track (anonymous) statistics, see https://github.com/capistrano/stats. This breaks automated deployment on continuous integration servers until the `.capistrano/metrics` file is created (with content `full` to simulate a "yes") via the interactive prompt or manually.

data/CONTRIBUTING.md

@@ -1,93 +1,61 @@
-## CONTRIBUTING
-
-**The issue tracker is intended exclusively for things that are genuine bugs,
-or improvements to the code.**
-
-If you have a user support query, or you suspect that you might just be holding
-it wrong, drop us a line at [the mailing list](https://groups.google.com/forum/#!forum/capistrano), [StackOverflow](http://stackoverflow.com/questions/tagged/capistrano) or at [CodersClan](http://codersclan.net/?repo_id=325&source=contributing). The
-mailing list is moderated to cut down on spam, so please be patient, if you use
-StackOverflow, make sure to tag your post with "Capistrano". (Not forgetting
-any other tags which might relate, rvm, rbenv, Ubuntu, etc.)
-
-If you have an urgent problem you can use [CodersClan](http://codersclan.net/?repo_id=325&source=contributing) to solve your problem quickly. CodersClan has a community of Capistrano experts dedicated to solve code problems for bounties.
-
-Wherever you post please be sure to include the version of Capistrano you are
-using, which versions of any plugins (*capistrano-rvm*, *capistrano-bundler*,
-etc.). Proper logs are vital, if you need to redact them, go ahead, but be
-careful not to remove anything important. Please take care to format logs and
-code correctly, ideally wrapped to a sane line length, and in a mono spaced
-font. This all helps us to gather a clear understanding of what is going wrong.
-
-**If you really think that you found a bug, or want to enquire about a feature,
-or send us a patch to add a feature, or fix a bug, please keep a few things in
-mind:**
-
-## When Submitting An Issue:
-
-If you think there's a bug, please make sure it's really a bug in Capistrano.
-As Capistrano sits on the (sometimes rough) edges between SSH, Git, the
-network, Ruby, RVM, rbenv, chruby, Bundler, your Linux distribution, countless
-shell configuration files on your end, and the server… there's a good chance
-the problem lies somewhere else.
-
-Please make sure you have reviewed the FAQs at http://www.capistranorb.com/.
-
-It's really important to include as much information as possible, versions of
-everything involved, anything weird you might be doing that might be having
-side effects, include as much as you can in a [GitHub
-Gist](https://gist.github.com/) and link that from the issue, with tools such
-as Gist, we can link to individual lines and help work out what is going wrong.
-
-If you are an experienced Ruby programmer, take a few minutes to get our test
-suite running, and do what you can to get a test case written that fails, from
-there we can understand exactly what it takes to reproduce the issue (as it's
-documented with code)
-
-## When Requesting a Feature:
-
-We can't make everyone happy all of the time, and we've been around the block
-well enough to know when something doesn't work well, or when your proposed fix
-might impact other things.
-
-We prefer to [start with
-"no"](https://gettingreal.37signals.com/ch05_Start_With_No.php), and help you
-find a better way to solve your problem, sometimes the solution is to [build
-faster
-horses](http://blog.cauvin.org/2010/07/henry-fords-faster-horse-quote.html),
-sometimes the solution is to work around it in a neat way that you didn't know
-existed.
-
-Please don't be offended if we say no, and don't be afraid to fight your
-corner, try and avoid being one of the [poisonous
-people](https://www.youtube.com/watch?v=Q52kFL8zVoM)
-
-## Submitting A Pull Request:
-
-Pull requests are awesome, and if they arrive with decent tests, and conform to
-the guidelines below, we'll merge them in as soon as possible, we'll let you
-know which release we're planning them for (we adhere to
-[semver](http://semver.org/) so please don't be upset if we plan your changes
-for a later release)
-
- * The code is MIT licenced, your code will fall under the same license if we merge it.
- * We can't merge it without a [good commit
-   message](http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message).
-   If you do this right, Github will use the commit message as the body of your
-   pull request, double win.
- * If you are referencing an improvement to an existing issue (if we have not
-   yet merged it )
- * Add an entry to the `CHANGELOG` under the `### master` section, but please
-   don't mess with the version.
- * If you add a new feature, please make sure to document it, open a
-   corresponding pull request in [the
-   documentation](https://github.com/capistrano/documentation) and mention the
-   code change pull request over there, and Github will link everything up. If
-   it's a simple feature, or a new variable, or something changed, it may be
-   appropriate simply to document it in the generated `Capfile` or `deploy.rb`, or
-   in the `README`
- * Take care to squash your commit into one single commit with a good message, it
-   saves us a lot of work in maintaining the CHANGELOG if we can generate it from
-   the commit messages between the release tags!
- * Tests! It's tricky to test some parts of Capistrano, but do your best, it
-   might just serve as a starting point for us to build a reliable test on top of,
-   and help us understand where you are coming from.
+**Hello and welcome!** Please look over this document before opening an issue or submitting a pull request to Capistrano.
+
+* [If you’re looking for help or have a question](#if-youre-looking-for-help-or-have-a-question)
+* [Reporting bugs](#reporting-bugs)
+* [Requesting new features or improvements](#requesting-new-features-or-improvements)
+* [Contributing code or documentation](#contributing-code-or-documentation)
+
+## If you’re looking for help or have a question
+
+**Check [Stack Overflow](http://stackoverflow.com/questions/tagged/capistrano) first if you need help using Capistrano.** You are more likely to get a quick response at Stack Overflow for common Capistrano topics. Make sure to tag your post with `capistrano` and/or `capistrano3` (not forgetting any other tags which might relate: rvm, rbenv, Ubuntu, etc.)
+
+If you have an urgent problem you can also try [CodersClan](http://codersclan.net/?repo_id=325&source=contributing), which has a community of Capistrano experts dedicated to solve code problems for bounties.
+
+When posting to Stack Overflow or CodersClan, be sure to include relevant information:
+
+* Capistrano version
+* Plugins and versions (capistrano-rvm, capistrano-bundler, etc.)
+* Logs and backtraces
+
+If you think you’ve found a bug in Capistrano itself, then…
+
+## Reporting bugs
+
+As much the Capistrano community tries to write good, well-tested code, bugs still happen. Sorry about that!
+
+**In case you’ve run across an already-known issue, check the FAQs first on the [official Capistrano site](http://capistranorb.com).**
+
+When opening a bug report, please include the output of the `cap <stage> doctor` task, e.g.:
+
+```
+cap production doctor
+```
+
+Also include in your report:
+
+* Versions of Ruby, Capistrano, and any plugins you’re using (if `doctor` didn't already do this for you)
+* A description of the troubleshooting steps you’ve taken
+* Logs and backtraces
+* Sections of your `deploy.rb` that may be relevant
+* Any other unique aspects of your environment
+
+If you are an experienced Ruby programmer, take a few minutes to get the Capistrano test suite running (see [DEVELOPMENT.md][]), and do what you can to get a test case written that fails. *This will be a huge help!*
+
+## Requesting new features or improvements
+
+Capistrano continues to improve thanks to people like you! Feel free to open a GitHub issue for any or all of these ideas:
+
+* New features that would make Capistrano even better
+* Areas where documentation could be improved
+* Ways to improve developer happiness
+
+Generally speaking the maintainers are very conservative about adding new features, and we can’t guarantee that the community will agree with or implement your idea. Please don’t be offended if we say no! The Capistrano team will do our best to review all suggestions and at least weigh in with a comment or suggest a workaround, if applicable.
+
+**Your idea will have a much better chance of becoming reality if you contribute code for it (even if the code is incomplete!).**
+
+## Contributing code or documentation
+
+So you want to contribute to Capistrano? Awesome! We have a whole separate document just you. It explains our pull request workflow and walks you through setting up the development environment: [DEVELOPMENT.md][].
+
+
+[DEVELOPMENT.md]: https://github.com/capistrano/capistrano/blob/master/DEVELOPMENT.md

data/DEVELOPMENT.md

@@ -0,0 +1,122 @@
+Thanks for helping build Capistrano! Here are the development practices followed by our community.
+
+* [Who can help](#who-can-help)
+* [Setting up your development environment](#setting-up-your-development-environment)
+* [Coding guidelines](#coding-guidelines)
+* [Submitting a pull request](#submitting-a-pull-request)
+* [Managing GitHub issues](#managing-github-issues)
+* [Reviewing and merging pull requests](#reviewing-and-merging-pull-requests)
+
+## Who can help
+
+Everyone can help improve Capistrano. There are ways to contribute even if you aren’t a Ruby programmer. Here’s what you can do to help the project:
+
+* adding to or fixing typos/quality in documentation
+* adding failing tests for reported bugs
+* writing code (no contribution is too small!)
+* reviewing pull requests and suggesting improvements
+* reporting bugs or suggesting new features (see [CONTRIBUTING.md][])
+
+## Setting up your development environment
+
+Capistrano is a Ruby project, so we expect you to have a functioning Ruby environment. To hack on Capistrano you will further need some specialized tools to run its test suite.
+
+Make sure to install:
+
+* [Bundler](https://bundler.io/) 1.10.5 (see note)
+* [Vagrant](https://www.vagrantup.com/)
+* [VirtualBox](https://www.virtualbox.org/wiki/Downloads) (or another [Vagrant-supported](https://docs.vagrantup.com/v2/getting-started/providers.html) VM host)
+
+*Note: As of this writing (December 2015), Vagrant does not work with Bundler > 1.10.5. If you have multiple versions of Bundler installed, use the special underscore command-line argument to force a compatible version, like this: `bundle _1.10.5_ exec rake features`.*
+
+### Running tests
+
+Capistrano has two test suites: an RSpec suite and a Cucumber suite. The RSpec suite handles quick feedback unit specs. The Cucumber suite is an integration suite that uses Vagrant to deploy to a real virtual server.
+
+```
+# Ensure all dependencies are installed
+$ bundle install
+
+# Run the RSpec suite
+$ bundle exec rake spec
+
+# Run the Cucumber suite (requires Bundler 1.10.5)
+$ bundle exec rake features
+
+# Run the Cucumber suite and leave the VM running (faster for subsequent runs)
+$ bundle exec rake features KEEP_RUNNING=1
+```
+
+### Report failing Cucumber features!
+
+Currently, the Capistrano Travis build does *not* run the Cucumber suite. This means it is possible for a failing Cucumber feature to sneak in without being noticed by our continuous integration checks.
+
+**If you come across a failing Cucumber feature, this is a bug.** Please report it by opening a GitHub issue. Or even better: do your best to fix the feature and submit a pull request!
+
+## Coding guidelines
+
+This project uses [RuboCop](https://github.com/bbatsov/rubocop) to enforce standard Ruby coding guidelines.
+
+* Test that your contributions pass with `rake rubocop`
+* Rubocop is also run as part of the full test suite with `rake`
+* Note the Travis build will fail and your PR cannot be merged if Rubocop finds errors
+
+## Submitting a pull request
+
+Pull requests are awesome, and if they arrive with decent tests, and conform to the guidelines below, we'll merge them in as soon as possible, we'll let you know which release we're planning them for (we adhere to [semver](http://semver.org/) so please don't be upset if we plan your changes for a later release).
+
+Your code should conform to these guidelines:
+
+ * The code is MIT licenced, your code will fall under the same license if we merge it.
+ * We can't merge it without a [good commit message](http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message). If you do this right, Github will use the commit message as the body of your pull request, double win.
+ * If you are making an improvement/fix for an existing issue, make sure to mention the issue number (if we have not yet merged it )
+ * Add an entry to the `CHANGELOG` under the `### master` section, but please don't mess with the version.
+ * If you add a new feature, please make sure to document it, open a corresponding pull request in [the documentation](https://github.com/capistrano/documentation) and mention the code change pull request over there, and Github will link everything up. If it's a simple feature, or a new variable, or something changed, it may be appropriate simply to document it in the generated `Capfile` or `deploy.rb`, or in the `README`
+ * Take care to squash your commit into one single commit with a good message, it saves us a lot of work in maintaining the CHANGELOG if we can generate it from the commit messages between the release tags!
+ * Tests! It's tricky to test some parts of Capistrano, but do your best, it might just serve as a starting point for us to build a reliable test on top of, and help us understand where you are coming from.
+
+## Managing GitHub issues
+
+The Capistrano maintainers will do our best to review all GitHub issues. Here’s how we manage issues:
+
+1. Issues will be acknowledged with an appropriate label (see below).
+2. Issues that are duplicates, spam, or irrelevant (e.g. wrong project), or are questions better suited for Stack Overflow (see [CONTRIBUTING.md][]) will be closed.
+3. Once an issue is fixed or resolved in an upcoming Capistrano release, it will be closed and assigned to a GitHub milestone for that upcoming version number.
+
+The maintainers do not have time to fix every issue ourselves, but we will gladly accept pull requests, especially for issues labeled as "you can help" (see below).
+
+### Issue labels
+
+Capistrano uses these GitHub labels to categorize issues:
+
+* **bug?** – Could be a bug (not reproducible or might be user error)
+* **confirmed bug** – Definitely a bug
+* **new feature** – A request for Capistrano to add a feature or work differently
+* **chore** – A TODO that is neither a bug nor a feature (e.g. improve docs, CI infrastructure, etc.)
+
+Also, the Capistrano team will sometimes add these labels to facilitate communication and encourage community feedback:
+
+* **discuss!** – The Capistrano team wants more feedback from the community on this issue; e.g. how a new feature should work, or whether a bug is serious or not.
+* **you can help!** – We want the community to help by submitting a pull request to solve a bug or add a feature. If you are looking for ways to contribute to Capistrano, start here!
+* **needs more info** – We need more info from the person who opened the issue; e.g. steps to reproduce a bug, clarification on a desired feature, etc.
+
+*These labels were inspired by Daniel Doubrovkine’s [2014 Golden Gate Ruby Conference talk](http://confreaks.tv/videos/gogaruco2014-taking-over-someone-else-s-open-source-projects).*
+
+## Reviewing and merging pull requests
+
+Pull requests and issues follow similar workflows. Before merging a pull request, the Capistrano maintainers will check that these requirements are met:
+
+* All CI checks pass
+* Significant changes in behavior or fixes mentioned in the CHANGELOG
+* Clean commit history
+* New features are documented
+* Code changes/additions are tested
+
+If any of these are missing, the **needs more info** label is assigned to the pull request to indicate the PR is incomplete.
+
+Merging a pull request is a decision entrusted to the maintainers of the Capistrano project. Any maintainer is free to merge a pull request if they feel the PR meets the above requirements and is in the best interest of the Capistrano community.
+
+After a pull request is merged, it is assigned to a GitHub milestone for the upcoming version number.
+
+
+[CONTRIBUTING.md]: https://github.com/capistrano/capistrano/blob/master/CONTRIBUTING.md