Skip to content
This repository was archived by the owner on Sep 24, 2019. It is now read-only.

Commit 0b8bb21

Browse files
author
Eric Thompson
committed
(QA-3110) update CONTRIBUTING doc to reflect new test layout
[skip ci]
1 parent da4ba6a commit 0b8bb21

File tree

1 file changed

+12
-26
lines changed

1 file changed

+12
-26
lines changed

CONTRIBUTING.md

Lines changed: 12 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -8,11 +8,11 @@
88
## Making Changes
99

1010
* Create a topic branch from where you want to base your work.
11-
* This is the `master` branch in the case of rototiller
12-
* To quickly create a topic branch based on master use `git checkout -b my_contribution master`. Do not work directly on the `master` branch.
11+
* This is the `master` branch for breaking changes in major version releases, the `stable` branch for non-breaking changes and bug-fixes in Y or Z releases.
12+
* To quickly create a topic branch based on master use `git checkout -b my_contribution master`. Do not work directly on the `master` nor `stable` branches.
1313
* Make commits of logical _working_ and _functional_ units.
1414
* Check for unnecessary whitespace with `git diff --check` before committing.
15-
* Make sure your commit messages are in the proper format.
15+
* Make sure your commit messages are in the proper format (a ticket ID is required in most cases).
1616

1717
(BKR-1234) Make the example in CONTRIBUTING imperative and concrete
1818

@@ -28,21 +28,24 @@
2828

2929
* Make sure you have added [RSpec](http://rspec.info/) tests that exercise your new code. These test should be located in the appropriate `rototiller/spec/` subdirectory. The addition of new methods/classes or the addition of code paths to existing methods/classes requires additional RSpec coverage.
3030
* One should **NOT USE** the deprecated `should`/`stub` methods - **USE** `expect`/`allow`. Use of deprecated RSpec methods will result in your patch being rejected. See a nice blog post from 2013 on [RSpec's new message expectation syntax](http://teaisaweso.me/blog/2013/05/27/rspecs-new-message-expectation-syntax/).
31-
* Run the spec unit tests to assure nothing else was accidentally broken, using `rake test`
32-
* **Bonus**: if possible ensure that `[bundle exec] rake test` runs without failures for additional Ruby versions (1.9, 2.0, etc). Rototiller supports Ruby 1.9+, and breakage of support for other rubies will cause a patch to be rejected.
33-
* Make sure that if you have added new functionality of sufficiently high risk, and it can not be covered adequately via unit tests (mocking, requires disk, other classes, etc), you also include acceptance tests in your PR.
31+
* Run the rspec unit tests to assure nothing else was accidentally broken, using `rake test`
32+
* **Bonus**: if possible ensure that `[bundle exec] rake test` runs without failures for additional Ruby versions (1.9, 2.0, etc). Rototiller supports Ruby 1.9.3+, and breakage of support for other rubies will cause a patch to be rejected.
33+
* Make sure that if you have added new functionality of sufficiently high risk, and it can not be covered adequately via unit tests (mocking, requires disk, other classes, etc).
34+
* you should also include integration or acceptance tests in your PR, where applicable
35+
* integration tests are unit tests that access the filesystem, network, or fully integrate the product
36+
* acceptance tests are typically end-to-end tests ensuring changes to installers, or behavior that is difficult to validate in integration.
3437
* Make sure that you have added documentation using [Yard](http://yardoc.org/), new methods/classes without appropriate documentation will be rejected.
3538
* Run the yardoc tool to ensure that your yard documentation is properly formatted and complete
3639
* `[bundle exec] rake docs:gen`
3740
* Yard docs are great for other developers, but often are difficult to read for users. If your change impacts user-facing functionality, please include changes to the human-readable markdown docs starting at README.md
38-
* During the time that you are working on your patch the master Rototiller branch may have changed - you'll want to [rebase](http://git-scm.com/book/en/Git-Branching-Rebasing) before you submit your PR with `git rebase master`. A successful rebase ensures that your patch will cleanly merge into Rototiller.
39-
* Submitted patches will be smoke tested through a series of acceptance level tests that ensures basic Rototiller functionality - the results of these tests will be evaluated by a Rototiller team member. Failures associated with the submitted patch will result in the patch being rejected.
41+
* During the time that you are working on your patch the master Rototiller branch may have changed - you'll want to [rebase](http://git-scm.com/book/en/Git-Branching-Rebasing) before you submit your PR with `git rebase master`. A successful rebase ensures that your patch will cleanly merge into the project.
42+
* Submitted patches will be smoke tested through a series of tests that ensures code standards, code functionality and user functionality - the results of these tests will be evaluated by a team member. Failures associated with the submitted patch will result in the patch being rejected.
4043

4144
## Submitting Changes
4245

4346
* Sign the [Contributor License Agreement](http://links.puppet.com/cla).
4447
* Push your changes to a topic branch in _your_ fork of the repository.
45-
* Submit a pull request to [Rototiller](https://github.com/puppetlabs/rototiller)
48+
* Submit a [pull request](http://help.github.com/send-pull-requests/) to [Rototiller](https://github.com/puppetlabs/rototiller)
4649
* PRs are reviewed as time permits.
4750

4851
# Additional Resources
@@ -55,20 +58,3 @@
5558
* [GitHub pull request documentation](http://help.github.com/send-pull-requests/)
5659
* Questions? Comments? Contact the Rototiller team at [email protected]
5760
* The keyword `rototiller` is monitored and we'll get back to you as quick as we can.
58-
* Rototiller's Architecture: [Rototiller's Architecture](docs/rototiller_class_graph.png)
59-
60-
## Submitting Changes
61-
62-
* Sign the [Contributor License Agreement](http://links.puppet.com/cla).
63-
* Push your changes to a topic branch in _your_ fork of the repository.
64-
* Submit a pull request to [Rototiller](https://github.com/puppetlabs/rototiller)
65-
* PRs are reviewed as time permits.
66-
67-
# Additional Resources
68-
69-
* [More information on contributing](http://links.puppet.com/contribute-to-puppet)
70-
* [Contributor License Agreement](http://links.puppet.com/cla)
71-
* [General GitHub documentation](http://help.github.com/)
72-
* [GitHub pull request documentation](http://help.github.com/send-pull-requests/)
73-
* Questions? Comments? Contact the Rototiller team at [email protected]
74-
* The keyword `rototiller` is monitored and we'll get back to you as quick as we can.

0 commit comments

Comments
 (0)