normal
- Fork puppet-tor.
- Create a topic branch against the develop branch.
git checkout develop; git checkout -b my_branch
- Make your change.
- Add a test for your change. Only refactoring and documentation changes require no new tests. If you are adding functionality or fixing a bug, please add a test.
- Run the tests. We only take pull requests with passing tests.
bundle exec rake spec SPEC_OPTS='--format documentation'
- Add or update documentation.
- Squash your commits down into logical components. Make sure to rebase against the current
develop
branch.git pull --rebase upstream develop
- Push to your branch.
git push origin my_branch
- Create a Pull Request from your branch against the develop branch.
- Fork puppet-tor.
- Create a feature.
git flow feature start my-feature
- Make your change.
- Add a test for your change. Only refactoring and documentation changes require no new tests. If you are adding functionality or fixing a bug, please add a test.
- Run the tests. We only take pull requests with passing tests.
bundle exec rake spec SPEC_OPTS='--format documentation'
- Add or update documentation.
- Squash your commits down into logical components. Make sure to rebase against the current
develop
branch.git pull --rebase upstream develop
- Publish your featue.
git flow feature publish my-feature
- Create a Pull Request from your branch against the develop branch.
Tests are written with rspec-puppet. CI is covered by Travis CI and the current status is visible here.
To install the test system, pick one of the following:
PUPPET_GEM_VERSION="~> 2.7.0" FACTER_GEM_VERSION="~> 1.7.0" bundle install --path=.vendor --without system_tests
PUPPET_GEM_VERSION="~> 3.0" bundle install --path=.vendor --without system_tests
PUPPET_GEM_VERSION="~> 4.0" bundle install --path=.vendor --without system_tests
To run all tests:
bundle exec rake validate && \
bundle exec rake lint && \
bundle exec rake metadata_lint && \
bundle exec rake spec SPEC_OPTS='--format documentation' FUTURE_PARSER="yes" STRICT_VARIABLES="no"
This repository is organized and maintained with the help of gitflow. Developers are encouraged to use it when working with this repository.
We use the following naming convention for branches:
- develop (during development)
- master (will be or has been released)
- feature/ (feature branches)
- release/ (release branches)
- hotfix/ (hotfix branches)
- (empty version prefix)
During development, you should work in feature branches instead of committing to master directly. Tell gitflow that you want to start working on a feature and it will do the work for you (like creating a branch prefixed with feature/):
git flow feature start <FEATURE_NAME>
The work in a feature branch should be kept close to the original problem. Tell gitflow that a feature is finished and it will merge it into master and push it to the upstream repository:
git flow feature finish <FEATURE_NAME>
Even before a feature is finished, you might want to make your branch available to other developers. You can do that by publishing it, which will push it to the upstream repository:
git flow feature publish <FEATURE_NAME>
To track a feature that is located in the upstream repository and not yet present locally, invoke the following command:
git flow feature track <FEATURE_NAME>
Changes that should go into production should come from the up-to-date master branch. Enter the "release to production" phase by running:
git flow release start <VERSION_NUMBER>
In this phase, only meta information should be touched, like bumping the version and update the history. Finish the release phase with:
git flow release finish <VERSION_NUMBER>
This project is versioned with the help of the Semantic Versioning Specification using 0.0.1 as the initial version. Please make sure you have read the guidelines before increasing a version number either for a release or a hotfix.