CONTRIBUTING.md 9.54 KB
Newer Older
Hailee Kenney's avatar
Hailee Kenney committed
1
# Contributing to Puppet modules
Colleen Murphy's avatar
Colleen Murphy committed
2

Hailee Kenney's avatar
Hailee Kenney committed
3 4 5
So you want to contribute to a Puppet module: Great! Below are some instructions to get you started doing
that very thing while setting expectations around code quality as well as a few tips for making the
process as easy as possible. 
Colleen Murphy's avatar
Colleen Murphy committed
6

Hailee Kenney's avatar
Hailee Kenney committed
7
### Table of Contents
Colleen Murphy's avatar
Colleen Murphy committed
8

Hailee Kenney's avatar
Hailee Kenney committed
9 10 11 12 13 14 15 16
1. [Getting Started](#getting-started)
1. [Commit Checklist](#commit-checklist)
1. [Submission](#submission)
1. [More about commits](#more-about-commits)
1. [Testing](#testing)
    - [Running Tests](#running-tests)
    - [Writing Tests](#writing-tests)
1. [Get Help](#get-help)
Colleen Murphy's avatar
Colleen Murphy committed
17

Hailee Kenney's avatar
Hailee Kenney committed
18
## Getting Started
Colleen Murphy's avatar
Colleen Murphy committed
19

Hailee Kenney's avatar
Hailee Kenney committed
20
- Fork the module repository on GitHub and clone to your workspace
Colleen Murphy's avatar
Colleen Murphy committed
21

Hailee Kenney's avatar
Hailee Kenney committed
22
- Make your changes!
Colleen Murphy's avatar
Colleen Murphy committed
23

Hailee Kenney's avatar
Hailee Kenney committed
24
## Commit Checklist
Colleen Murphy's avatar
Colleen Murphy committed
25

Hailee Kenney's avatar
Hailee Kenney committed
26
### The Basics
Colleen Murphy's avatar
Colleen Murphy committed
27

Hailee Kenney's avatar
Hailee Kenney committed
28
- [x] my commit is a single logical unit of work
Colleen Murphy's avatar
Colleen Murphy committed
29

Hailee Kenney's avatar
Hailee Kenney committed
30
- [x] I have checked for unnecessary whitespace with "git diff --check" 
Colleen Murphy's avatar
Colleen Murphy committed
31

Hailee Kenney's avatar
Hailee Kenney committed
32
- [x] my commit does not include commented out code or unneeded files
Colleen Murphy's avatar
Colleen Murphy committed
33

Hailee Kenney's avatar
Hailee Kenney committed
34
### The Content
Colleen Murphy's avatar
Colleen Murphy committed
35

Hailee Kenney's avatar
Hailee Kenney committed
36
- [x] my commit includes tests for the bug I fixed or feature I added
Colleen Murphy's avatar
Colleen Murphy committed
37

Hailee Kenney's avatar
Hailee Kenney committed
38 39 40
- [x] my commit includes appropriate documentation changes if it is introducing a new feature or changing existing functionality
    
- [x] my code passes existing test suites
Colleen Murphy's avatar
Colleen Murphy committed
41

Hailee Kenney's avatar
Hailee Kenney committed
42
### The Commit Message
Colleen Murphy's avatar
Colleen Murphy committed
43

Hailee Kenney's avatar
Hailee Kenney committed
44
- [x] the first line of my commit message includes:
Colleen Murphy's avatar
Colleen Murphy committed
45

Hailee Kenney's avatar
Hailee Kenney committed
46 47 48
  - [x] an issue number (if applicable), e.g. "(MODULES-xxxx) This is the first line" 
  
  - [x] a short description (50 characters is the soft limit, excluding ticket number(s))
Colleen Murphy's avatar
Colleen Murphy committed
49

Hailee Kenney's avatar
Hailee Kenney committed
50
- [x] the body of my commit message:
Colleen Murphy's avatar
Colleen Murphy committed
51

Hailee Kenney's avatar
Hailee Kenney committed
52
  - [x] is meaningful
Colleen Murphy's avatar
Colleen Murphy committed
53

Hailee Kenney's avatar
Hailee Kenney committed
54
  - [x] uses the imperative, present tense: "change", not "changed" or "changes"
Colleen Murphy's avatar
Colleen Murphy committed
55

Hailee Kenney's avatar
Hailee Kenney committed
56
  - [x] includes motivation for the change, and contrasts its implementation with the previous behavior
Colleen Murphy's avatar
Colleen Murphy committed
57

Hailee Kenney's avatar
Hailee Kenney committed
58 59 60 61 62 63 64 65 66 67 68 69 70 71 72
## Submission

### Pre-requisites

- Make sure you have a [GitHub account](https://github.com/join)

- [Create a ticket](https://tickets.puppet.com/secure/CreateIssue!default.jspa), or [watch the ticket](https://tickets.puppet.com/browse/) you are patching for.

### Push and PR

- Push your changes to your fork

- [Open a Pull Request](https://help.github.com/articles/creating-a-pull-request-from-a-fork/) against the repository in the puppetlabs organization

## More about commits 
Colleen Murphy's avatar
Colleen Murphy committed
73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106

  1.  Make separate commits for logically separate changes.

      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.

      If you are going to refactor a piece of code, please do so as a
      separate commit from your feature or bug fix changes.

      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.

      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.

      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.

      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.

107
  2.  Sending your patches
Colleen Murphy's avatar
Colleen Murphy committed
108 109 110

      To submit your changes via a GitHub pull request, we _highly_
      recommend that you have them on a topic branch, instead of
111
      directly on "main".
Colleen Murphy's avatar
Colleen Murphy committed
112 113 114 115 116 117 118
      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
Hailee Kenney's avatar
Hailee Kenney committed
119
      [creating pull requests](https://help.github.com/articles/creating-a-pull-request-from-a-fork/).
Colleen Murphy's avatar
Colleen Murphy committed
120 121 122 123 124 125

      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.

Hailee Kenney's avatar
Hailee Kenney committed
126
  3.  Update the related JIRA issue.
Colleen Murphy's avatar
Colleen Murphy committed
127

Hailee Kenney's avatar
Hailee Kenney committed
128
      If there is a JIRA issue associated with the change you
Colleen Murphy's avatar
Colleen Murphy committed
129 130 131 132
      submitted, then you should update the ticket to include the
      location of your branch, along with any other commentary you
      may wish to make.

Hailee Kenney's avatar
Hailee Kenney committed
133
# Testing
Colleen Murphy's avatar
Colleen Murphy committed
134

Hailee Kenney's avatar
Hailee Kenney committed
135
## Getting Started
Colleen Murphy's avatar
Colleen Murphy committed
136

Hailee Kenney's avatar
Hailee Kenney committed
137
Our Puppet modules provide [`Gemfile`](./Gemfile)s, which can tell a Ruby package manager such as [bundler](http://bundler.io/) what Ruby packages,
Colleen Murphy's avatar
Colleen Murphy committed
138 139
or Gems, are required to build, develop, and test this software.

Hailee Kenney's avatar
Hailee Kenney committed
140 141
Please make sure you have [bundler installed](http://bundler.io/#getting-started) on your system, and then use it to 
install all dependencies needed for this project in the project root by running
Colleen Murphy's avatar
Colleen Murphy committed
142 143

```shell
Hailee Kenney's avatar
Hailee Kenney committed
144
% bundle install --path .bundle/gems
Colleen Murphy's avatar
Colleen Murphy committed
145 146 147 148 149 150 151 152 153 154 155 156 157
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.
```

Hailee Kenney's avatar
Hailee Kenney committed
158
NOTE: some systems may require you to run this command with sudo.
Colleen Murphy's avatar
Colleen Murphy committed
159 160 161 162 163 164 165

If you already have those gems installed, make sure they are up-to-date:

```shell
% bundle update
```

Hailee Kenney's avatar
Hailee Kenney committed
166 167 168 169 170
## Running Tests

With all dependencies in place and up-to-date, run the tests:

### Unit Tests
Colleen Murphy's avatar
Colleen Murphy committed
171 172

```shell
173
% bundle exec rake spec
Colleen Murphy's avatar
Colleen Murphy committed
174 175
```

Hailee Kenney's avatar
Hailee Kenney committed
176 177
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. 
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),
Colleen Murphy's avatar
Colleen Murphy committed
178 179
rspec tests define them in [.fixtures.yml](./fixtures.yml).

Hailee Kenney's avatar
Hailee Kenney committed
180 181 182 183 184
### Acceptance Tests

Some Puppet modules also come with acceptance tests, which use [beaker][]. These tests spin up a virtual machine under
[VirtualBox](https://www.virtualbox.org/), controlled with [Vagrant](http://www.vagrantup.com/), to simulate scripted test
scenarios. In order to run these, you need both Virtualbox and Vagrant installed on your system.
Colleen Murphy's avatar
Colleen Murphy committed
185

Hailee Kenney's avatar
Hailee Kenney committed
186
Run the tests by issuing the following command
Colleen Murphy's avatar
Colleen Murphy committed
187 188

```shell
189 190
% bundle exec rake spec_clean
% bundle exec rspec spec/acceptance
Colleen Murphy's avatar
Colleen Murphy committed
191 192 193
```

This will now download a pre-fabricated image configured in the [default node-set](./spec/acceptance/nodesets/default.yml),
Hailee Kenney's avatar
Hailee Kenney committed
194
install Puppet, copy this module, and install its dependencies per [spec/spec_helper_acceptance.rb](./spec/spec_helper_acceptance.rb)
Colleen Murphy's avatar
Colleen Murphy committed
195 196
and then run all the tests under [spec/acceptance](./spec/acceptance).

Hailee Kenney's avatar
Hailee Kenney committed
197 198 199
## Writing Tests

### Unit Tests
Colleen Murphy's avatar
Colleen Murphy committed
200

Hailee Kenney's avatar
Hailee Kenney committed
201 202 203
When writing unit tests for Puppet, [rspec-puppet][] is your best friend. It provides tons of helper methods for testing your manifests against a 
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] 
but here's a tiny sample:
Colleen Murphy's avatar
Colleen Murphy committed
204

Hailee Kenney's avatar
Hailee Kenney committed
205
Sample manifest:
Colleen Murphy's avatar
Colleen Murphy committed
206

Hailee Kenney's avatar
Hailee Kenney committed
207 208 209 210 211 212 213 214
```puppet
file { "a test file":
  ensure => present,
  path   => "/etc/sample",
}
```

Sample test:
Colleen Murphy's avatar
Colleen Murphy committed
215

Hailee Kenney's avatar
Hailee Kenney committed
216 217 218 219 220
```ruby
it 'does a thing' do
  expect(subject).to contain_file("a test file").with({:path => "/etc/sample"})
end
```
Colleen Murphy's avatar
Colleen Murphy committed
221

Hailee Kenney's avatar
Hailee Kenney committed
222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243
### Acceptance Tests

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
twice to check for idempotency or errors, then run expectations.

```ruby
it 'does an end-to-end thing' do
  pp = <<-EOF
    file { 'a test file': 
      ensure  => present,
      path    => "/etc/sample",
      content => "test string",
    }
    
  apply_manifest(pp, :catch_failures => true)
  apply_manifest(pp, :catch_changes => true)
  
end

describe file("/etc/sample") do
  it { is_expected.to contain "test string" }
end
Colleen Murphy's avatar
Colleen Murphy committed
244

Hailee Kenney's avatar
Hailee Kenney committed
245
```
Colleen Murphy's avatar
Colleen Murphy committed
246

Hailee Kenney's avatar
Hailee Kenney committed
247
# If you have commit access to the repository
Colleen Murphy's avatar
Colleen Murphy committed
248

Hailee Kenney's avatar
Hailee Kenney committed
249 250 251
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
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
all changes go through a code review process.**
Colleen Murphy's avatar
Colleen Murphy committed
252

Hailee Kenney's avatar
Hailee Kenney committed
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.
Colleen Murphy's avatar
Colleen Murphy committed
254

Hailee Kenney's avatar
Hailee Kenney committed
255 256 257 258 259 260
# Get Help

### On the web
* [Puppet help messageboard](http://puppet.com/community/get-help)
* [Writing tests](https://docs.puppet.com/guides/module_guides/bgtm.html#step-three-module-testing)
* [General GitHub documentation](http://help.github.com/)
Jeff McCune's avatar
Jeff McCune committed
261
* [GitHub pull request documentation](http://help.github.com/send-pull-requests/)
Hailee Kenney's avatar
Hailee Kenney committed
262 263 264 265 266 267 268 269 270 271

### On chat
* Slack (slack.puppet.com) #forge-modules, #puppet-dev, #windows, #voxpupuli
* IRC (freenode) #puppet-dev, #voxpupuli


[rspec-puppet]: http://rspec-puppet.com/
[rspec-puppet_docs]: http://rspec-puppet.com/documentation/
[beaker]: https://github.com/puppetlabs/beaker
[beaker-rspec]: https://github.com/puppetlabs/beaker-rspec