Skip to content

Latest commit

 

History

History
88 lines (59 loc) · 4.42 KB

CONTRIBUTING.md

File metadata and controls

88 lines (59 loc) · 4.42 KB
Raw

Contributing

normal

  1. Fork puppet-openlldp.
  2. Create a topic branch against the develop branch. git checkout develop; git checkout -b my_branch
  3. Make your change.
  4. 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.
  5. Run the tests. We only take pull requests with passing tests. bundle exec rake spec SPEC_OPTS='--format documentation'
  6. Add or update documentation.
  7. Squash your commits down into logical components. Make sure to rebase against the current develop branch. git pull --rebase upstream develop
  8. Push to your branch. git push origin my_branch
  9. Create a Pull Request from your branch against the develop branch.

git-flow

  1. Fork puppet-openlldp.
  2. Create a feature. git flow feature start my-feature
  3. Make your change.
  4. 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.
  5. Run the tests. We only take pull requests with passing tests. bundle exec rake spec SPEC_OPTS='--format documentation'
  6. Add or update documentation.
  7. Squash your commits down into logical components. Make sure to rebase against the current develop branch. git pull --rebase upstream develop
  8. Publish your featue. git flow feature publish my-feature
  9. Create a Pull Request from your branch against the develop branch.

Testing

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"

Branching

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>

Versioning

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.