diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index 38cacd4..f3ffb57 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -1,3 +1,18 @@ +# Contribution guidelines + +## Table of contents + +* [Contributing](#contributing) +* [Writing proper commits - short version](#writing-proper-commits-short-version) +* [Writing proper commits - long version](#writing-proper-commits-long-version) +* [Dependencies](#dependencies) + * [Note for OS X users](#note-for-os-x-users) +* [The test matrix](#the-test-matrix) +* [Syntax and style](#syntax-and-style) +* [Running the unit tests](#running-the-unit-tests) +* [Unit tests in docker](#unit-tests-in-docker) +* [Integration tests](#integration-tests) + This module has grown over time based on a range of contributions from people using it. If you follow these contributing guidelines your patch will likely make it into a release a little more quickly. @@ -8,29 +23,92 @@ Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms. [Contributor Code of Conduct](https://voxpupuli.org/coc/). -1. Fork the repo. - -1. Create a separate branch for your change. - -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 [our docs](https://voxpupuli.org/docs/#reviewing-a-module-pr) we - use to review a module and the [official styleguide](https://puppet.com/docs/puppet/6.0/style_guide.html). - 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 our current master. - -1. Push the branch to your fork and submit a pull request. - -Please be prepared to repeat some of these steps as our contributors review -your code. +* Fork the repo. +* Create a separate branch for your change. +* 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](#the-test-matrix). +* Checkout [our docs](https://voxpupuli.org/docs/reviewing_pr/) we use to review a module and the [official styleguide](https://puppet.com/docs/puppet/6.0/style_guide.html). They provide some guidance for new code that might help you before you submit a pull request. +* 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. +* Squash your commits down into logical components. Make sure to rebase against our current master. +* Push the branch to your fork and submit a pull request. + +Please be prepared to repeat some of these steps as our contributors review your code. + +## Writing proper commits - short version + +* Make commits of logical units. +* Check for unnecessary whitespace with "git diff --check" before committing. +* Commit using Unix line endings (check the settings around "crlf" in git-config(1)). +* Do not check in commented out code or unneeded files. +* The first line of the commit message should be a short description (50 characters is the soft limit, excluding ticket number(s)), and should skip the full stop. +* Associate the issue in the message. The first line should include the issue number in the form "(#XXXX) Rest of message". +* The body should provide a meaningful commit message, which: + *uses the imperative, present tense: `change`, not `changed` or `changes`. + * includes motivation for the change, and contrasts its implementation with the previous behavior. + * Make sure that you have tests for the bug you are fixing, or feature you are adding. + * Make sure the test suites passes after your commit: + * When introducing a new feature, make sure it is properly documented in the README.md + +## Writing proper commits - long version + + 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. + + 2. Sending your patches + + To submit your changes via a GitHub pull request, we _highly_ + recommend that you have them on a topic branch, instead of + directly on `master`. + 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 + [creating pull requests](http://help.github.com/send-pull-requests/). + + 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. + + + 3. Update the related GitHub issue. + + If there is a GitHub issue associated with the change you + submitted, then you should update the ticket to include the + location of your branch, along with any other commentary you + may wish to make. ## Dependencies @@ -75,13 +153,15 @@ BUNDLE_JOBS="$(nproc)" ### Note for OS X users -`nproc` isn't a valid command unter OS x. As an alternative, you can do: +`nproc` isn't a valid command under OS x. As an alternative, you can do: ```sh --jobs "$(sysctl -n hw.ncpu)" ``` -## Syntax and style +## The test matrix + +### Syntax and style The test suite will run [Puppet Lint](http://puppet-lint.com/) and [Puppet Syntax](https://github.com/gds-operations/puppet-syntax) to @@ -99,7 +179,7 @@ against it. You can run those locally ahead of time with: bundle exec rake rubocop ``` -## Running the unit tests +### Running the unit tests The unit test suite covers most of the code, as mentioned above please add tests if you're adding new functionality. If you've not used @@ -124,7 +204,7 @@ To run a specific spec test set the `SPEC` variable: bundle exec rake spec SPEC=spec/foo_spec.rb ``` -### Unit tests in docker +#### Unit tests in docker Some people don't want to run the dependencies locally or don't want to install ruby. We ship a Dockerfile that enables you to run all unit tests and linting. @@ -139,7 +219,7 @@ permission to talk to it. You can specify a remote docker host by setting the `DOCKER_HOST` environment variable. it will copy the content of the module into the docker image. So it will not work if a Gemfile.lock exists. -## Integration tests +### Integration tests The unit tests just check the code runs, not that it does exactly what we want on a real machine. For that we're using diff --git a/.msync.yml b/.msync.yml index 23dfa32..a7c0bbf 100644 --- a/.msync.yml +++ b/.msync.yml @@ -1 +1 @@ -modulesync_config_version: '2.8.0' +modulesync_config_version: '2.9.0' diff --git a/.travis.yml b/.travis.yml index a98ed62..54b70f3 100644 --- a/.travis.yml +++ b/.travis.yml @@ -1,5 +1,5 @@ --- -dist: xenial +dist: bionic language: ruby cache: bundler before_install: diff --git a/Dockerfile b/Dockerfile index 67048bb..6fd6342 100644 --- a/Dockerfile +++ b/Dockerfile @@ -15,7 +15,7 @@ RUN bundle install --without system_tests development release --path=${BUNDLE_PA COPY . . RUN bundle install -RUN bundle exec release_checks +RUN bundle exec rake release_checks # Container should not saved RUN exit 1 diff --git a/Gemfile b/Gemfile index 9571ef3..5a2e737 100644 --- a/Gemfile +++ b/Gemfile @@ -12,7 +12,7 @@ end group :test do gem 'puppetlabs_spec_helper', '>= 2.14.0', :require => false - gem 'rspec-puppet-facts', '>= 1.8.0', :require => false + gem 'rspec-puppet-facts', '>= 1.9.5', :require => false gem 'rspec-puppet-utils', :require => false gem 'puppet-lint-leading_zero-check', :require => false gem 'puppet-lint-trailing_comma-check', :require => false @@ -22,6 +22,8 @@ group :test do gem 'puppet-lint-variable_contains_upcase', :require => false gem 'puppet-lint-absolute_classname-check', :require => false gem 'puppet-lint-topscope-variable-check', :require => false + gem 'puppet-lint-legacy_facts-check', :require => false + gem 'puppet-lint-anchor-check', :require => false gem 'metadata-json-lint', :require => false gem 'redcarpet', :require => false gem 'rubocop', '~> 0.49.1', :require => false @@ -63,9 +65,9 @@ group :system_tests do end group :release do - gem 'github_changelog_generator', :require => false, :git => 'https://github.com/github-changelog-generator/github-changelog-generator' + gem 'github_changelog_generator', :require => false, :git => 'https://github.com/voxpupuli/github-changelog-generator', :branch => 'voxpupuli_essential_fixes' gem 'puppet-blacksmith', :require => false - gem 'voxpupuli-release', :require => false, :git => 'https://github.com/voxpupuli/voxpupuli-release-gem' + gem 'voxpupuli-release', :require => false gem 'puppet-strings', '>= 2.2', :require => false end diff --git a/Rakefile b/Rakefile index 09701d0..e3642ac 100644 --- a/Rakefile +++ b/Rakefile @@ -77,6 +77,19 @@ begin metadata = JSON.load(File.read(metadata_json)) config.project = metadata['name'] end + + # Workaround for https://github.com/github-changelog-generator/github-changelog-generator/issues/715 + require 'rbconfig' + if RbConfig::CONFIG['host_os'] =~ /linux/ + task :changelog do + puts 'Fixing line endings...' + changelog_file = File.join(__dir__, 'CHANGELOG.md') + changelog_txt = File.read(changelog_file) + new_contents = changelog_txt.gsub(%r{\r\n}, "\n") + File.open(changelog_file, "w") {|file| file.puts new_contents } + end + end + rescue LoadError end # vim: syntax=ruby diff --git a/spec/spec_helper.rb b/spec/spec_helper.rb index f7b30c8..2c83dc8 100644 --- a/spec/spec_helper.rb +++ b/spec/spec_helper.rb @@ -10,6 +10,11 @@ require 'bundler' include RspecPuppetFacts +if ENV['DEBUG'] + Puppet::Util::Log.level = :debug + Puppet::Util::Log.newdestination(:console) +end + if File.exist?(File.join(__dir__, 'default_module_facts.yml')) facts = YAML.load(File.read(File.join(__dir__, 'default_module_facts.yml'))) if facts @@ -37,6 +42,18 @@ end RSpec.configure do |c| + # getting the correct facter version is tricky. We use facterdb as a source to mock facts + # see https://github.com/camptocamp/facterdb + # people might provide a specific facter version. In that case we use it. + # Otherwise we need to match the correct facter version to the used puppet version. + # as of 2019-10-31, puppet 5 ships facter 3.11 and puppet 6 ships facter 3.14 + # https://puppet.com/docs/puppet/5.5/about_agent.html + c.default_facter_version = if ENV['FACTERDB_FACTS_VERSION'] + ENV['FACTERDB_FACTS_VERSION'] + else + Gem::Dependency.new('', ENV['PUPPET_VERSION']).match?('', '5') ? '3.11.0' : '3.14.0' + end + # Coverage generation c.after(:suite) do RSpec::Puppet::Coverage.report!