|
| 1 | +This module has grown over time based on a range of contributions from |
| 2 | +people using it. If you follow these contributing guidelines your patch |
| 3 | +will likely make it into a release a little more quickly. |
| 4 | + |
| 5 | +## Contributing |
| 6 | + |
| 7 | +Please note that this project is released with a Contributor Code of Conduct. |
| 8 | +By participating in this project you agree to abide by its terms. |
| 9 | +[Contributor Code of Conduct](https://voxpupuli.org/coc/). |
| 10 | + |
| 11 | +1. Fork the repo. |
| 12 | + |
| 13 | +1. Create a separate branch for your change. |
| 14 | + |
| 15 | +1. Run the tests. We only take pull requests with passing tests, and |
| 16 | + documentation. |
| 17 | + |
| 18 | +1. Add a test for your change. Only refactoring and documentation |
| 19 | + changes require no new tests. If you are adding functionality |
| 20 | + or fixing a bug, please add a test. |
| 21 | + |
| 22 | +1. Squash your commits down into logical components. Make sure to rebase |
| 23 | + against the current master. |
| 24 | + |
| 25 | +1. Push the branch to your fork and submit a pull request. |
| 26 | + |
| 27 | +Please be prepared to repeat some of these steps as our contributors review |
| 28 | +your code. |
| 29 | + |
| 30 | +## Dependencies |
| 31 | + |
| 32 | +The testing and development tools have a bunch of dependencies, |
| 33 | +all managed by [bundler](http://bundler.io/) according to the |
| 34 | +[Puppet support matrix](http://docs.puppetlabs.com/guides/platforms.html#ruby-versions). |
| 35 | + |
| 36 | +By default the tests use a baseline version of Puppet. |
| 37 | + |
| 38 | +If you have Ruby 2.x or want a specific version of Puppet, |
| 39 | +you must set an environment variable such as: |
| 40 | + |
| 41 | + export PUPPET_VERSION="~> 4.2.0" |
| 42 | + |
| 43 | +You can install all needed gems for spec tests into the modules directory by |
| 44 | +running: |
| 45 | + |
| 46 | +```sh |
| 47 | +bundle install --path .vendor/ --without development --without system_tests --without release |
| 48 | +``` |
| 49 | + |
| 50 | +If you also want to run acceptance tests: |
| 51 | + |
| 52 | +```sh |
| 53 | +bundle install --path .vendor/ --without development --with system_tests --without release |
| 54 | +``` |
| 55 | + |
| 56 | +Our all in one solution if you don't know if you need to install or update gems: |
| 57 | + |
| 58 | +```sh |
| 59 | +bundle install --path .vendor/ --without development --with system_tests --without release; bundle update; bundle clean |
| 60 | +``` |
| 61 | + |
| 62 | +## Syntax and style |
| 63 | + |
| 64 | +The test suite will run [Puppet Lint](http://puppet-lint.com/) and |
| 65 | +[Puppet Syntax](https://github.com/gds-operations/puppet-syntax) to |
| 66 | +check various syntax and style things. You can run these locally with: |
| 67 | + |
| 68 | + bundle exec rake lint |
| 69 | + bundle exec rake validate |
| 70 | + |
| 71 | +It will also run some [Rubocop](http://batsov.com/rubocop/) tests |
| 72 | +against it. You can run those locally ahead of time with: |
| 73 | + |
| 74 | + bundle exec rake rubocop |
| 75 | + |
| 76 | +## Running the unit tests |
| 77 | + |
| 78 | +The unit test suite covers most of the code, as mentioned above please |
| 79 | +add tests if you're adding new functionality. If you've not used |
| 80 | +[rspec-puppet](http://rspec-puppet.com/) before then feel free to ask |
| 81 | +about how best to test your new feature. |
| 82 | + |
| 83 | +To run the linter, the syntax checker and the unit tests: |
| 84 | + |
| 85 | + bundle exec rake test |
| 86 | + |
| 87 | +To run your all the unit tests |
| 88 | + |
| 89 | + bundle exec rake spec SPEC_OPTS='--format documentation' |
| 90 | + |
| 91 | +To run a specific spec test set the `SPEC` variable: |
| 92 | + |
| 93 | + bundle exec rake spec SPEC=spec/foo_spec.rb |
| 94 | + |
| 95 | +## Integration tests |
| 96 | + |
| 97 | +The unit tests just check the code runs, not that it does exactly what |
| 98 | +we want on a real machine. For that we're using |
| 99 | +[beaker](https://github.com/puppetlabs/beaker). |
| 100 | + |
| 101 | +This fires up a new virtual machine (using vagrant) and runs a series of |
| 102 | +simple tests against it after applying the module. You can run this |
| 103 | +with: |
| 104 | + |
| 105 | + bundle exec rake acceptance |
| 106 | + |
| 107 | +This will run the tests on the module's default nodeset. You can override the |
| 108 | +nodeset used, e.g., |
| 109 | + |
| 110 | + BEAKER_set=centos-7-x64 bundle exec rake acceptance |
| 111 | + |
| 112 | +There are default rake tasks for the various acceptance test modules, e.g., |
| 113 | + |
| 114 | + bundle exec rake beaker:centos-7-x64 |
| 115 | + bundle exec rake beaker:ssh:centos-7-x64 |
| 116 | + |
| 117 | +If you don't want to have to recreate the virtual machine every time you can |
| 118 | +use `BEAKER_destroy=no` and `BEAKER_provision=no`. On the first run you will at |
| 119 | +least need `BEAKER_provision` set to yes (the default). The Vagrantfile for the |
| 120 | +created virtual machines will be in `.vagrant/beaker_vagrant_files`. |
| 121 | + |
| 122 | +The easiest way to debug in a docker container is to open a shell: |
| 123 | + |
| 124 | + docker exec -it -u root ${container_id_or_name} bash |
0 commit comments