Thanks for helping build Capistrano! Here are the development practices followed by our community.
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:
Improvements and additions to Capistrano's documentation are very much appreciated. The official documentation is stored in the docs/
directory as Markdown files. These files are used to automatically generate the capistranorb.com website, which is hosted by GitHub Pages. Feel free to make changes to this documentation as you see fit. Before opening a pull request, make sure your documentation renders correctly by previewing the website in your local environment. Refer to docs/README.md for instructions.
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:
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
$ bundle exec rake features
# Run the Cucumber suite and leave the VM running (faster for subsequent runs)
$ bundle exec rake features KEEP_RUNNING=1
This project uses RuboCop to enforce standard Ruby coding guidelines.
rake rubocop
rake
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 so please don't be upset if we plan your changes for a later release).
Your code should conform to these guidelines:
CHANGELOG
under the ### master
section, but please don't mess with the version.docs/
(see contributing documentation, above). 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
.The Capistrano maintainers will do our best to review all GitHub issues. Here’s how we manage issues:
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).
Capistrano uses these GitHub labels to categorize issues:
Also, the Capistrano team will sometimes add these labels to facilitate communication and encourage community feedback:
These labels were inspired by Daniel Doubrovkine’s 2014 Golden Gate Ruby Conference talk.
Pull requests and issues follow similar workflows. Before merging a pull request, the Capistrano maintainers will check that these requirements are met:
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.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。