Mercurial > repos > other > Puppet
comparison modules/concat/CONTRIBUTING.md @ 275:d9352a684e62
Mass update of modules to remove deprecation warnings
author | IBBoard <dev@ibboard.co.uk> |
---|---|
date | Sun, 26 Jan 2020 11:36:07 +0000 |
parents | 37675581a273 |
children | adf6fe9bbc17 |
comparison
equal
deleted
inserted
replaced
274:b2571c28fc27 | 275:d9352a684e62 |
---|---|
1 Checklist (and a short version for the impatient) | 1 # Contributing to Puppet modules |
2 ================================================= | 2 |
3 | 3 So you want to contribute to a Puppet module: Great! Below are some instructions to get you started doing |
4 * Commits: | 4 that very thing while setting expectations around code quality as well as a few tips for making the |
5 | 5 process as easy as possible. |
6 - Make commits of logical units. | 6 |
7 | 7 ### Table of Contents |
8 - Check for unnecessary whitespace with "git diff --check" before | 8 |
9 committing. | 9 1. [Getting Started](#getting-started) |
10 | 10 1. [Commit Checklist](#commit-checklist) |
11 - Commit using Unix line endings (check the settings around "crlf" in | 11 1. [Submission](#submission) |
12 git-config(1)). | 12 1. [More about commits](#more-about-commits) |
13 | 13 1. [Testing](#testing) |
14 - Do not check in commented out code or unneeded files. | 14 - [Running Tests](#running-tests) |
15 | 15 - [Writing Tests](#writing-tests) |
16 - The first line of the commit message should be a short | 16 1. [Get Help](#get-help) |
17 description (50 characters is the soft limit, excluding ticket | 17 |
18 number(s)), and should skip the full stop. | 18 ## Getting Started |
19 | 19 |
20 - Associate the issue in the message. The first line should include | 20 - Fork the module repository on GitHub and clone to your workspace |
21 the issue number in the form "(#XXXX) Rest of message". | 21 |
22 | 22 - Make your changes! |
23 - The body should provide a meaningful commit message, which: | 23 |
24 | 24 ## Commit Checklist |
25 - uses the imperative, present tense: "change", not "changed" or | 25 |
26 "changes". | 26 ### The Basics |
27 | 27 |
28 - includes motivation for the change, and contrasts its | 28 - [x] my commit is a single logical unit of work |
29 implementation with the previous behavior. | 29 |
30 | 30 - [x] I have checked for unnecessary whitespace with "git diff --check" |
31 - Make sure that you have tests for the bug you are fixing, or | 31 |
32 feature you are adding. | 32 - [x] my commit does not include commented out code or unneeded files |
33 | 33 |
34 - Make sure the test suites passes after your commit: | 34 ### The Content |
35 `bundle exec rspec spec/acceptance` More information on [testing](#Testing) below | 35 |
36 | 36 - [x] my commit includes tests for the bug I fixed or feature I added |
37 - When introducing a new feature, make sure it is properly | 37 |
38 documented in the README.md | 38 - [x] my commit includes appropriate documentation changes if it is introducing a new feature or changing existing functionality |
39 | 39 |
40 * Submission: | 40 - [x] my code passes existing test suites |
41 | 41 |
42 * Pre-requisites: | 42 ### The Commit Message |
43 | 43 |
44 - Make sure you have a [GitHub account](https://github.com/join) | 44 - [x] the first line of my commit message includes: |
45 | 45 |
46 - [Create a ticket](https://tickets.puppetlabs.com/secure/CreateIssue!default.jspa), or [watch the ticket](https://tickets.puppetlabs.com/browse/) you are patching for. | 46 - [x] an issue number (if applicable), e.g. "(MODULES-xxxx) This is the first line" |
47 | 47 |
48 * Preferred method: | 48 - [x] a short description (50 characters is the soft limit, excluding ticket number(s)) |
49 | 49 |
50 - Fork the repository on GitHub. | 50 - [x] the body of my commit message: |
51 | 51 |
52 - Push your changes to a topic branch in your fork of the | 52 - [x] is meaningful |
53 repository. (the format ticket/1234-short_description_of_change is | 53 |
54 usually preferred for this project). | 54 - [x] uses the imperative, present tense: "change", not "changed" or "changes" |
55 | 55 |
56 - Submit a pull request to the repository in the puppetlabs | 56 - [x] includes motivation for the change, and contrasts its implementation with the previous behavior |
57 organization. | 57 |
58 | 58 ## Submission |
59 The long version | 59 |
60 ================ | 60 ### Pre-requisites |
61 | |
62 - Make sure you have a [GitHub account](https://github.com/join) | |
63 | |
64 - [Create a ticket](https://tickets.puppet.com/secure/CreateIssue!default.jspa), or [watch the ticket](https://tickets.puppet.com/browse/) you are patching for. | |
65 | |
66 ### Push and PR | |
67 | |
68 - Push your changes to your fork | |
69 | |
70 - [Open a Pull Request](https://help.github.com/articles/creating-a-pull-request-from-a-fork/) against the repository in the puppetlabs organization | |
71 | |
72 ## More about commits | |
61 | 73 |
62 1. Make separate commits for logically separate changes. | 74 1. Make separate commits for logically separate changes. |
63 | 75 |
64 Please break your commits down into logically consistent units | 76 Please break your commits down into logically consistent units |
65 which include new or changed tests relevant to the rest of the | 77 which include new or changed tests relevant to the rest of the |
102 is merged in. | 114 is merged in. |
103 | 115 |
104 GitHub has some pretty good | 116 GitHub has some pretty good |
105 [general documentation](http://help.github.com/) on using | 117 [general documentation](http://help.github.com/) on using |
106 their site. They also have documentation on | 118 their site. They also have documentation on |
107 [creating pull requests](http://help.github.com/send-pull-requests/). | 119 [creating pull requests](https://help.github.com/articles/creating-a-pull-request-from-a-fork/). |
108 | 120 |
109 In general, after pushing your topic branch up to your | 121 In general, after pushing your topic branch up to your |
110 repository on GitHub, you can switch to the branch in the | 122 repository on GitHub, you can switch to the branch in the |
111 GitHub UI and click "Pull Request" towards the top of the page | 123 GitHub UI and click "Pull Request" towards the top of the page |
112 in order to open a pull request. | 124 in order to open a pull request. |
113 | 125 |
114 | 126 3. Update the related JIRA issue. |
115 3. Update the related GitHub issue. | 127 |
116 | 128 If there is a JIRA issue associated with the change you |
117 If there is a GitHub issue associated with the change you | |
118 submitted, then you should update the ticket to include the | 129 submitted, then you should update the ticket to include the |
119 location of your branch, along with any other commentary you | 130 location of your branch, along with any other commentary you |
120 may wish to make. | 131 may wish to make. |
121 | 132 |
122 Testing | 133 # Testing |
123 ======= | 134 |
124 | 135 ## Getting Started |
125 Getting Started | 136 |
126 --------------- | 137 Our Puppet modules provide [`Gemfile`](./Gemfile)s, which can tell a Ruby package manager such as [bundler](http://bundler.io/) what Ruby packages, |
127 | |
128 Our puppet modules provide [`Gemfile`](./Gemfile)s which can tell a ruby | |
129 package manager such as [bundler](http://bundler.io/) what Ruby packages, | |
130 or Gems, are required to build, develop, and test this software. | 138 or Gems, are required to build, develop, and test this software. |
131 | 139 |
132 Please make sure you have [bundler installed](http://bundler.io/#getting-started) | 140 Please make sure you have [bundler installed](http://bundler.io/#getting-started) on your system, and then use it to |
133 on your system, then use it to install all dependencies needed for this project, | 141 install all dependencies needed for this project in the project root by running |
134 by running | 142 |
135 | 143 ```shell |
136 ```shell | 144 % bundle install --path .bundle/gems |
137 % bundle install | |
138 Fetching gem metadata from https://rubygems.org/........ | 145 Fetching gem metadata from https://rubygems.org/........ |
139 Fetching gem metadata from https://rubygems.org/.. | 146 Fetching gem metadata from https://rubygems.org/.. |
140 Using rake (10.1.0) | 147 Using rake (10.1.0) |
141 Using builder (3.2.2) | 148 Using builder (3.2.2) |
142 -- 8><-- many more --><8 -- | 149 -- 8><-- many more --><8 -- |
146 Using bundler (1.3.5) | 153 Using bundler (1.3.5) |
147 Your bundle is complete! | 154 Your bundle is complete! |
148 Use `bundle show [gemname]` to see where a bundled gem is installed. | 155 Use `bundle show [gemname]` to see where a bundled gem is installed. |
149 ``` | 156 ``` |
150 | 157 |
151 NOTE some systems may require you to run this command with sudo. | 158 NOTE: some systems may require you to run this command with sudo. |
152 | 159 |
153 If you already have those gems installed, make sure they are up-to-date: | 160 If you already have those gems installed, make sure they are up-to-date: |
154 | 161 |
155 ```shell | 162 ```shell |
156 % bundle update | 163 % bundle update |
157 ``` | 164 ``` |
158 | 165 |
159 With all dependencies in place and up-to-date we can now run the tests: | 166 ## Running Tests |
160 | 167 |
161 ```shell | 168 With all dependencies in place and up-to-date, run the tests: |
162 % rake spec | 169 |
163 ``` | 170 ### Unit Tests |
164 | 171 |
165 This will execute all the [rspec tests](http://rspec-puppet.com/) tests | 172 ```shell |
166 under [spec/defines](./spec/defines), [spec/classes](./spec/classes), | 173 % bundle exec rake spec |
167 and so on. rspec tests may have the same kind of dependencies as the | 174 ``` |
168 module they are testing. While the module defines in its [Modulefile](./Modulefile), | 175 |
176 This executes all the [rspec tests](http://rspec-puppet.com/) in the directories defined [here](https://github.com/puppetlabs/puppetlabs_spec_helper/blob/699d9fbca1d2489bff1736bb254bb7b7edb32c74/lib/puppetlabs_spec_helper/rake_tasks.rb#L17) and so on. | |
177 rspec tests may have the same kind of dependencies as the module they are testing. Although the module defines these dependencies in its [metadata.json](./metadata.json), | |
169 rspec tests define them in [.fixtures.yml](./fixtures.yml). | 178 rspec tests define them in [.fixtures.yml](./fixtures.yml). |
170 | 179 |
171 Some puppet modules also come with [beaker](https://github.com/puppetlabs/beaker) | 180 ### Acceptance Tests |
172 tests. These tests spin up a virtual machine under | 181 |
173 [VirtualBox](https://www.virtualbox.org/)) with, controlling it with | 182 Some Puppet modules also come with acceptance tests, which use [beaker][]. These tests spin up a virtual machine under |
174 [Vagrant](http://www.vagrantup.com/) to actually simulate scripted test | 183 [VirtualBox](https://www.virtualbox.org/), controlled with [Vagrant](http://www.vagrantup.com/), to simulate scripted test |
175 scenarios. In order to run these, you will need both of those tools | 184 scenarios. In order to run these, you need both Virtualbox and Vagrant installed on your system. |
176 installed on your system. | 185 |
177 | 186 Run the tests by issuing the following command |
178 You can run them by issuing the following command | 187 |
179 | 188 ```shell |
180 ```shell | 189 % bundle exec rake spec_clean |
181 % rake spec_clean | 190 % bundle exec rspec spec/acceptance |
182 % rspec spec/acceptance | |
183 ``` | 191 ``` |
184 | 192 |
185 This will now download a pre-fabricated image configured in the [default node-set](./spec/acceptance/nodesets/default.yml), | 193 This will now download a pre-fabricated image configured in the [default node-set](./spec/acceptance/nodesets/default.yml), |
186 install puppet, copy this module and install its dependencies per [spec/spec_helper_acceptance.rb](./spec/spec_helper_acceptance.rb) | 194 install Puppet, copy this module, and install its dependencies per [spec/spec_helper_acceptance.rb](./spec/spec_helper_acceptance.rb) |
187 and then run all the tests under [spec/acceptance](./spec/acceptance). | 195 and then run all the tests under [spec/acceptance](./spec/acceptance). |
188 | 196 |
189 Writing Tests | 197 ## Writing Tests |
190 ------------- | 198 |
191 | 199 ### Unit Tests |
192 XXX getting started writing tests. | 200 |
193 | 201 When writing unit tests for Puppet, [rspec-puppet][] is your best friend. It provides tons of helper methods for testing your manifests against a |
194 If you have commit access to the repository | 202 catalog (e.g. contain_file, contain_package, with_params, etc). It would be ridiculous to try and top rspec-puppet's [documentation][rspec-puppet_docs] |
195 =========================================== | 203 but here's a tiny sample: |
196 | 204 |
197 Even if you have commit access to the repository, you will still need to | 205 Sample manifest: |
198 go through the process above, and have someone else review and merge | 206 |
199 in your changes. The rule is that all changes must be reviewed by a | 207 ```puppet |
200 developer on the project (that did not write the code) to ensure that | 208 file { "a test file": |
201 all changes go through a code review process. | 209 ensure => present, |
202 | 210 path => "/etc/sample", |
203 Having someone other than the author of the topic branch recorded as | 211 } |
204 performing the merge is the record that they performed the code | 212 ``` |
205 review. | 213 |
206 | 214 Sample test: |
207 | 215 |
208 Additional Resources | 216 ```ruby |
209 ==================== | 217 it 'does a thing' do |
210 | 218 expect(subject).to contain_file("a test file").with({:path => "/etc/sample"}) |
211 * [Getting additional help](http://puppetlabs.com/community/get-help) | 219 end |
212 | 220 ``` |
213 * [Writing tests](http://projects.puppetlabs.com/projects/puppet/wiki/Development_Writing_Tests) | 221 |
214 | 222 ### Acceptance Tests |
215 * [Patchwork](https://patchwork.puppetlabs.com) | 223 |
216 | 224 Writing acceptance tests for Puppet involves [beaker][] and its cousin [beaker-rspec][]. A common pattern for acceptance tests is to create a test manifest, apply it |
225 twice to check for idempotency or errors, then run expectations. | |
226 | |
227 ```ruby | |
228 it 'does an end-to-end thing' do | |
229 pp = <<-EOF | |
230 file { 'a test file': | |
231 ensure => present, | |
232 path => "/etc/sample", | |
233 content => "test string", | |
234 } | |
235 | |
236 apply_manifest(pp, :catch_failures => true) | |
237 apply_manifest(pp, :catch_changes => true) | |
238 | |
239 end | |
240 | |
241 describe file("/etc/sample") do | |
242 it { is_expected.to contain "test string" } | |
243 end | |
244 | |
245 ``` | |
246 | |
247 # If you have commit access to the repository | |
248 | |
249 Even if you have commit access to the repository, you still need to go through the process above, and have someone else review and merge | |
250 in your changes. The rule is that **all changes must be reviewed by a project developer that did not write the code to ensure that | |
251 all changes go through a code review process.** | |
252 | |
253 The record of someone performing the merge is the record that they performed the code review. Again, this should be someone other than the author of the topic branch. | |
254 | |
255 # Get Help | |
256 | |
257 ### On the web | |
258 * [Puppet help messageboard](http://puppet.com/community/get-help) | |
259 * [Writing tests](https://docs.puppet.com/guides/module_guides/bgtm.html#step-three-module-testing) | |
217 * [General GitHub documentation](http://help.github.com/) | 260 * [General GitHub documentation](http://help.github.com/) |
218 | |
219 * [GitHub pull request documentation](http://help.github.com/send-pull-requests/) | 261 * [GitHub pull request documentation](http://help.github.com/send-pull-requests/) |
220 | 262 |
263 ### On chat | |
264 * Slack (slack.puppet.com) #forge-modules, #puppet-dev, #windows, #voxpupuli | |
265 * IRC (freenode) #puppet-dev, #voxpupuli | |
266 | |
267 | |
268 [rspec-puppet]: http://rspec-puppet.com/ | |
269 [rspec-puppet_docs]: http://rspec-puppet.com/documentation/ | |
270 [beaker]: https://github.com/puppetlabs/beaker | |
271 [beaker-rspec]: https://github.com/puppetlabs/beaker-rspec |