1. Create a separate branch for your change.
-1. Run the tests. We only take pull requests with passing tests, and
- documentation.
+1. We only take pull requests with passing tests, and documentation. [travis-ci](http://travis-ci.org)
+ runs the tests for us. You can also execute them locally. This is explained
+ in a later section.
+
+1. Checkout the docs we use to review a module. They provide some guidance for
+ new code that might help you before you submit a pull request.
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.
1. Squash your commits down into logical components. Make sure to rebase
- against the current master.
+ against our current master.
1. Push the branch to your fork and submit a pull request.
If you have Ruby 2.x or want a specific version of Puppet,
you must set an environment variable such as:
- export PUPPET_VERSION="~> 4.2.0"
+```sh
+export PUPPET_VERSION="~> 5.5.6"
+```
You can install all needed gems for spec tests into the modules directory by
running:
[Puppet Syntax](https://github.com/gds-operations/puppet-syntax) to
check various syntax and style things. You can run these locally with:
- bundle exec rake lint
- bundle exec rake validate
+```sh
+bundle exec rake lint
+bundle exec rake validate
+```
It will also run some [Rubocop](http://batsov.com/rubocop/) tests
against it. You can run those locally ahead of time with:
- bundle exec rake rubocop
+```sh
+bundle exec rake rubocop
+```
## Running the unit tests
To run the linter, the syntax checker and the unit tests:
- bundle exec rake test
+```sh
+bundle exec rake test
+```
To run your all the unit tests
- bundle exec rake spec SPEC_OPTS='--format documentation'
+```sh
+bundle exec rake spec
+```
To run a specific spec test set the `SPEC` variable:
- bundle exec rake spec SPEC=spec/foo_spec.rb
+```sh
+bundle exec rake spec SPEC=spec/foo_spec.rb
+```
## Integration tests
simple tests against it after applying the module. You can run this
with:
- bundle exec rake acceptance
+```sh
+bundle exec rake acceptance
+```
This will run the tests on the module's default nodeset. You can override the
nodeset used, e.g.,
- BEAKER_set=centos-7-x64 bundle exec rake acceptance
+```sh
+BEAKER_set=centos-7-x64 bundle exec rake acceptance
+```
There are default rake tasks for the various acceptance test modules, e.g.,
- bundle exec rake beaker:centos-7-x64
- bundle exec rake beaker:ssh:centos-7-x64
+```sh
+bundle exec rake beaker:centos-7-x64
+bundle exec rake beaker:ssh:centos-7-x64
+```
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_files`.
+Beaker also supports docker containers. We also use that in our automated CI
+pipeline at [travis-ci](http://travis-ci.org). To use that instead of Vagrant:
+
+```
+PUPPET_INSTALL_TYPE=agent BEAKER_IS_PE=no BEAKER_PUPPET_COLLECTION=puppet5 BEAKER_debug=true BEAKER_setfile=debian9-64{hypervisor=docker} BEAKER_destroy=yes bundle exec rake beaker
+```
+
+You can replace the string `debian9` with any common operating system.
+The following strings are known to work:
+
+* ubuntu1604
+* ubuntu1804
+* debian8
+* debian9
+* centos6
+* centos7
+
The easiest way to debug in a docker container is to open a shell:
- docker exec -it -u root ${container_id_or_name} bash
+```sh
+docker exec -it -u root ${container_id_or_name} bash
+```
+
+The source of this file is in our [modulesync_config](https://github.com/voxpupuli/modulesync_config/blob/master/moduleroot/.github/CONTRIBUTING.md.erb)
+repository.