comparison modules/firewall/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 d6f2a0ee45c0
children 66c406eec60d
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