From 8473912c31aa08e0453789ed31cbd63aa344de15 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Igor=20Gali=C4=87?= Date: Fri, 8 Jan 2016 12:38:04 +0100 Subject: Update from voxpupuli modulesync_config --- CONTRIBUTING.md | 218 ++++++++++++++------------------------------------------ 1 file changed, 54 insertions(+), 164 deletions(-) (limited to 'CONTRIBUTING.md') diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e164306..1ccfba6 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,195 +1,85 @@ -Checklist (and a short version for the impatient) -================================================= +This module has grown over time based on a range of contributions from +people using it. If you follow these contributing guidelines your patch +will likely make it into a release a little quicker. - * Commits: - - Make commits of logical units. +## Contributing - - Check for unnecessary whitespace with "git diff --check" before - committing. +Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms. [Contributor Code of Conduct](https://voxpupuli.org/coc/). - - Commit using Unix line endings (check the settings around "crlf" in - git-config(1)). +1. Fork the repo. - - Do not check in commented out code or unneeded files. +1. Create a separate branch for your change. - - The first line of the commit message should be a short - description (50 characters is the soft limit, excluding ticket - number(s)), and should skip the full stop. +1. Run the tests. We only take pull requests with passing tests, and + documentation. - - Associate the issue in the message. If any issue exists in the body of - the commit a line like "Closes: #XXX" or "Mentions: #XXX" is expected. +1. 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. - - The body should provide a meaningful commit message, which: +1. Squash your commits down into logical components. Make sure to rebase + against the current master. - - uses the imperative, present tense: "change", not "changed" or - "changes". +1. Push the branch to your fork and submit a pull request. - - includes motivation for the change, and contrasts its - implementation with the previous behavior. +Please be prepared to repeat some of these steps as our contributors review +your code. - - Make sure that you have tests for the bug you are fixing, or - feature you are adding. +## Dependencies - - Make sure the test suites passes after your commit: - `bundle exec rake spec` More information on [testing](#Testing) below +The testing and development tools have a bunch of dependencies, +all managed by [bundler](http://bundler.io/) according to the +[Puppet support matrix](http://docs.puppetlabs.com/guides/platforms.html#ruby-versions). - - When introducing a new feature, make sure it is properly - documented in the README.md +By default the tests use a baseline version of Puppet. - * Submission: +If you have Ruby 2.x or want a specific version of Puppet, +you must set an environment variable such as: - * Pre-requisites: + export PUPPET_VERSION="~> 4.2.0" - - Make sure you have a [GitHub account](https://github.com/join) +Install the dependencies like so... - * Preferred method: + bundle install - - Fork the repository on GitHub. +## Syntax and style - - Push your changes to a topic branch in your fork of the repository. +The test suite will run [Puppet Lint](http://puppet-lint.com/) and +[Puppet Syntax](https://github.com/gds-operations/puppet-syntax) to +check various syntax and style things. You can run these locally with: - - Submit a pull request to the repository in the puppet-community namespace. + bundle exec rake test -The long version -================ +## Running the unit tests - 1. Make separate commits for logically separate changes. +The unit test suite covers most of the code, as mentioned above please +add tests if you're adding new functionality. If you've not used +[rspec-puppet](http://rspec-puppet.com/) before then feel free to ask +about how best to test your new feature. To run your specific spec test +you can pass it to `SPEC`: - Please break your commits down into logically consistent units - which include new or changed tests relevant to the rest of the - change. The goal of doing this is to make the diff easier to - read for whoever is reviewing your code. In general, the easier - your diff is to read, the more likely someone will be happy to - review it and get it into the code base. + bundle exec rake spec SPEC=spec/foo_spec.rb - If you are going to refactor a piece of code, please do so as a - separate commit from your feature or bug fix changes. +## Integration tests - We also really appreciate changes that include tests to make - sure the bug is not re-introduced, and that the feature is not - accidentally broken. +The unit tests just check the code runs, not that it does exactly what +we want on a real machine. For that we're using +[beaker](https://github.com/puppetlabs/beaker). - Describe the technical detail of the change(s). If your - description starts to get too long, that is a good sign that you - probably need to split up your commit into more finely grained - pieces. +This fires up a new virtual machine (using vagrant) and runs a series of +simple tests against it after applying the module. You can run this +with: - Commits which plainly describe the things which help - reviewers check the patch and future developers understand the - code are much more likely to be merged in with a minimum of - bike-shedding or requested changes. Ideally, the commit message - would include information, and be in a form suitable for - inclusion in the release notes for the version of Puppet that - includes them. + bundle exec rake acceptance - Please also check that you are not introducing any trailing - whitespace or other "whitespace errors". You can do this by - running "git diff --check" on your changes before you commit. +This will run the tests on an Ubuntu 12.04 virtual machine. You can also +run the integration tests against Centos 6.5 with. - 2. Sending your patches + RS_SET=centos-64-x64 bundle exec rake acceptances - To submit your changes via a GitHub pull request, we _highly_ - recommend that you have them on a topic branch, instead of - directly on "master". +If you don't want to have to recreate the virtual machine every time you +can use `BEAKER_DESTROY=no` and `BEAKER_PROVISION=no`. On the first run you will +at least need `BEAKER_PROVISION` set to yes (the default). The Vagrantfile +for the created virtual machines will be in `.vagrant/beaker_vagrant_fies`. - It makes things much easier to keep track of, especially if - you decide to work on another thing before your first change - is merged in. - - GitHub has some pretty good - [general documentation](http://help.github.com/) on using - their site. They also have documentation on - [creating pull requests](http://help.github.com/send-pull-requests/). - - In general, after pushing your topic branch up to your - repository on GitHub, you can switch to the branch in the - GitHub UI and click "Pull Request" towards the top of the page - in order to open a pull request. - - - 3. Update the related GitHub issue. - - If there is a GitHub issue associated with the change you - submitted, then you should update the ticket to include the - location of your branch, along with any other commentary you - may wish to make. - -Testing -======= - -Getting Started ---------------- - -Our puppet modules provide [`Gemfile`](./Gemfile)s which can tell a ruby -package manager such as [bundler](http://bundler.io/) what Ruby packages, -or Gems, are required to build, develop, and test this software. - -Please make sure you have [bundler installed](http://bundler.io/#getting-started) -on your system, then use it to install all dependencies needed for this project, -by running - -```shell -% bundle install -Fetching gem metadata from https://rubygems.org/........ -Fetching gem metadata from https://rubygems.org/.. -Using rake (10.1.0) -Using builder (3.2.2) --- 8><-- many more --><8 -- -Using rspec-system-puppet (2.2.0) -Using serverspec (0.6.3) -Using rspec-system-serverspec (1.0.0) -Using bundler (1.3.5) -Your bundle is complete! -Use `bundle show [gemname]` to see where a bundled gem is installed. -``` - -NOTE some systems may require you to run this command with `sudo`. - -If you already have those gems installed, make sure they are up-to-date: - -```shell -% bundle update -``` - -With all dependencies in place and up-to-date we can now run the tests: - -```shell -% rake spec -``` - -This will execute all the [rspec tests](http://rspec-puppet.com/) tests -under [spec/defines](./spec/defines), [spec/classes](./spec/classes), -and so on. rspec tests may have the same kind of dependencies as the -module they are testing. While the module defines in its [Modulefile](./Modulefile), -rspec tests define them in [.fixtures.yml](./fixtures.yml). - -Writing Tests -------------- - -XXX getting started writing tests. - -If you have commit access to the repository -=========================================== - -Even if you have commit access to the repository, you will still need to -go through the process above, and have someone else review and merge -in your changes. The rule is that all changes must be reviewed by a -developer on the project (that did not write the code) to ensure that -all changes go through a code review process. - -Having someone other than the author of the topic branch recorded as -performing the merge is the record that they performed the code -review. - - -Additional Resources -==================== - -* [Getting additional help](http://puppetlabs.com/community/get-help) - -* [Writing tests](http://projects.puppetlabs.com/projects/puppet/wiki/Development_Writing_Tests) - -* [General GitHub documentation](http://help.github.com/) - -* [GitHub pull request documentation](http://help.github.com/send-pull-requests/) -- cgit v1.2.3