modulesync 4.0.0-10-g1c946c3

.editorconfig

@@ -0,0 +1,14 @@
+# editorconfig.org
+
+# MANAGED BY MODULESYNC
+
+root = true
+
+[*]
+charset = utf-8
+end_of_line = lf
+indent_size = 2
+tab_width = 2
+indent_style = space
+insert_final_newline = true
+trim_trailing_whitespace = true

.github/CONTRIBUTING.md

@@ -0,0 +1,282 @@
+# 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.
+
+## Contributing
+
+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/).
+
+* 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.
+
+Also consider sending in your profile code that calls this component module as an acceptance test or provide it via an issue. This helps reviewers a lot to test your use case and prevents future regressions!
+
+## 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
+
+The testing and development tools have a bunch of dependencies,
+all managed by [bundler](http://bundler.io/) according to the
+[Puppet support matrix](http://docs.puppetlabs.com/guides/platforms.html#ruby-versions).
+
+By default the tests use a baseline version of Puppet.
+
+If you have Ruby 2.x or want a specific version of Puppet,
+you must set an environment variable such as:
+
+```sh
+export PUPPET_VERSION="~> 5.5.6"
+```
+
+You can install all needed gems for spec tests into the modules directory by
+running:
+
+```sh
+bundle install --path .vendor/ --without development system_tests release --jobs "$(nproc)"
+```
+
+If you also want to run acceptance tests:
+
+```sh
+bundle install --path .vendor/ --with system_tests --without development release --jobs "$(nproc)"
+```
+
+Our all in one solution if you don't know if you need to install or update gems:
+
+```sh
+bundle install --path .vendor/ --with system_tests --without development release --jobs "$(nproc)"; bundle update; bundle clean
+```
+
+As an alternative to the `--jobs "$(nproc)` parameter, you can set an
+environment variable:
+
+```sh
+BUNDLE_JOBS="$(nproc)"
+```
+
+### Note for OS X users
+
+`nproc` isn't a valid command under OS x. As an alternative, you can do:
+
+```sh
+--jobs "$(sysctl -n hw.ncpu)"
+```
+
+## 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
+check various syntax and style things. You can run these locally with:
+
+```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:
+
+```sh
+bundle exec rake rubocop
+```
+
+### 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
+[rspec-puppet](http://rspec-puppet.com/) before then feel free to ask
+about how best to test your new feature.
+
+To run the linter, the syntax checker and the unit tests:
+
+```sh
+bundle exec rake test
+```
+
+To run your all the unit tests
+
+```sh
+bundle exec rake spec
+```
+
+To run a specific spec test set the `SPEC` variable:
+
+```sh
+bundle exec rake spec SPEC=spec/foo_spec.rb
+```
+
+#### 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.
+You only need to run:
+
+```sh
+docker build .
+```
+
+Please ensure that a docker daemon is running and that your user has the
+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
+
+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
+[beaker](https://github.com/puppetlabs/beaker).
+
+This fires up a new virtual machine (using vagrant) and runs a series of
+simple tests against it after applying the module. You can run this
+with:
+
+```sh
+bundle exec rake beaker
+```
+
+This will run the tests on the module's default nodeset. You can override the
+nodeset used, e.g.,
+
+```sh
+BEAKER_set=centos-7-x64 bundle exec rake beaker
+```
+
+There are default rake tasks for the various acceptance test modules, e.g.,
+
+```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:
+
+```sh
+PUPPET_INSTALL_TYPE=agent BEAKER_IS_PE=no BEAKER_PUPPET_COLLECTION=puppet6 BEAKER_debug=true BEAKER_setfile=debian10-64{hypervisor=docker} BEAKER_destroy=yes bundle exec rake beaker
+```
+
+You can replace the string `debian10` with any common operating system.
+The following strings are known to work:
+
+* ubuntu1604
+* ubuntu1804
+* ubuntu2004
+* debian9
+* debian10
+* centos7
+* centos8
+
+The easiest way to debug in a docker container is to open a shell:
+
+```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.

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,26 @@
+<!--
+Thank you for contributing to this project!
+
+- This project has a Contributor Code of Conduct: https://voxpupuli.org/coc/
+- Please check that here is no existing issue or PR that addresses your problem.
+- Please fill the following form to enable us to help you.
+- Our vulnerabilities reporting process is at https://voxpupuli.org/security/
+
+-->
+
+## Affected Puppet, Ruby, OS and module versions/distributions
+
+- Puppet:
+- Ruby:
+- Distribution:
+- Module version:
+
+## How to reproduce (e.g Puppet code you use)
+
+## What are you seeing
+
+## What behaviour did you expect instead
+
+## Output log
+
+## Any additional information you'd like to impart

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,20 @@
+<!--
+Thank you for contributing to this project!
+
+- This project has a Contributor Code of Conduct: https://voxpupuli.org/coc/
+- Please check that here is no existing issue or PR that addresses your problem.
+- Our vulnerabilities reporting process is at https://voxpupuli.org/security/
+
+-->
+#### Pull Request (PR) description
+<!--
+Replace this comment with a description of your pull request.
+-->
+
+#### This Pull Request (PR) fixes the following issues
+<!--
+Replace this comment with the list of issues or n/a.
+Use format:
+Fixes #123
+Fixes #124
+-->

.github/SECURITY.md

@@ -0,0 +1,3 @@
+# Vox Pupuli Security Policy
+
+Our vulnerabilities reporting process is at https://voxpupuli.org/security/

.github/workflows/ci.yml

@@ -0,0 +1,47 @@
+name: CI
+
+on: pull_request
+
+jobs:
+  setup_matrix:
+    name: 'Setup Test Matrix'
+    runs-on: ubuntu-latest
+    outputs:
+      beaker_setfiles: ${{ steps.get-outputs.outputs.beaker_setfiles }}
+      puppet_major_versions: ${{ steps.get-outputs.outputs.puppet_major_versions }}
+      puppet_unit_test_matrix: ${{ steps.get-outputs.outputs.puppet_unit_test_matrix }}
+    env:
+      BUNDLE_WITHOUT: development:test:release
+    steps:
+      - uses: actions/checkout@v2
+      - name: Setup ruby
+        uses: ruby/setup-ruby@v1
+        with:
+          ruby-version: '2.7'
+          bundler-cache: true
+      - name: Run rake validate
+        run: bundle exec rake validate
+      - name: Setup Test Matrix
+        id: get-outputs
+        run: bundle exec metadata2gha --use-fqdn --pidfile-workaround false
+
+  unit:
+    needs: setup_matrix
+    runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        include: ${{fromJson(needs.setup_matrix.outputs.puppet_unit_test_matrix)}}
+    env:
+      BUNDLE_WITHOUT: development:system_tests:release
+      PUPPET_VERSION: "~> ${{ matrix.puppet }}.0"
+    name: Puppet ${{ matrix.puppet }} (Ruby ${{ matrix.ruby }})
+    steps:
+      - uses: actions/checkout@v2
+      - name: Setup ruby
+        uses: ruby/setup-ruby@v1
+        with:
+          ruby-version: ${{ matrix.ruby }}
+          bundler-cache: true
+      - name: Run tests
+        run: bundle exec rake

.github/workflows/release.yml

@@ -0,0 +1,29 @@
+name: Release
+
+on:
+  push:
+    tags:
+      - '*'
+
+env:
+  BUNDLE_WITHOUT: development:test:system_tests
+
+jobs:
+  deploy:
+    name: 'deploy to forge'
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v2
+      - name: Setup Ruby
+        uses: ruby/setup-ruby@v1
+        with:
+          ruby-version: '2.7'
+          bundler-cache: true
+      - name: Build and Deploy
+        env:
+          # Configure secrets here:
+          #  https://docs.github.com/en/free-pro-team@latest/actions/reference/encrypted-secrets
+          BLACKSMITH_FORGE_USERNAME: '${{ secrets.PUPPET_FORGE_USERNAME }}'
+          BLACKSMITH_FORGE_API_KEY: '${{ secrets.PUPPET_FORGE_API_KEY }}'
+        run: bundle exec rake module:push

.gitignore

@@ -0,0 +1,20 @@
+pkg/
+Gemfile.lock
+Gemfile.local
+vendor/
+.vendor/
+spec/fixtures/manifests/
+spec/fixtures/modules/
+.vagrant/
+.bundle/
+.ruby-version
+coverage/
+log/
+.idea/
+.dependencies/
+.librarian/
+Puppetfile.lock
+*.iml
+.*.sw?
+.yardoc/
+Guardfile

.msync.yml

@@ -0,0 +1,2 @@
+---
+modulesync_config_version: '4.0.0'

.overcommit.yml

@@ -0,0 +1,64 @@
+# Managed by https://github.com/voxpupuli/modulesync_configs
+#
+# Hooks are only enabled if you take action.
+#
+# To enable the hooks run:
+#
+# ```
+# bundle exec overcommit --install
+# # ensure .overcommit.yml does not harm to you and then
+# bundle exec overcommit --sign
+# ```
+#
+# (it will manage the .git/hooks directory):
+#
+# Examples howto skip a test for a commit or push:
+#
+# ```
+# SKIP=RuboCop git commit
+# SKIP=PuppetLint git commit
+# SKIP=RakeTask git push
+# ```
+#
+# Don't invoke overcommit at all:
+#
+# ```
+# OVERCOMMIT_DISABLE=1 git commit
+# ```
+#
+# Read more about overcommit: https://github.com/brigade/overcommit
+#
+# To manage this config yourself in your module add
+#
+# ```
+# .overcommit.yml:
+#   unmanaged: true
+# ```
+#
+# to your modules .sync.yml config
+---
+PreCommit:
+  RuboCop:
+    enabled: true
+    description: 'Runs rubocop on modified files only'
+    command: ['bundle', 'exec', 'rubocop']
+  PuppetLint:
+    enabled: true
+    description: 'Runs puppet-lint on modified files only'
+    command: ['bundle', 'exec', 'puppet-lint']
+  YamlSyntax:
+    enabled: true
+  JsonSyntax:
+    enabled: true
+  TrailingWhitespace:
+    enabled: true
+
+PrePush:
+  RakeTarget:
+    enabled: true
+    description: 'Run rake targets'
+    targets:
+      - 'validate'
+      - 'test'
+      - 'rubocop'
+    command: ['bundle', 'exec', 'rake']

.pmtignore

@@ -0,0 +1,34 @@
+docs/
+pkg/
+Gemfile
+Gemfile.lock
+Gemfile.local
+vendor/
+.vendor/
+spec/
+Rakefile
+.vagrant/
+.bundle/
+.ruby-version
+coverage/
+log/
+.idea/
+.dependencies/
+.github/
+.librarian/
+Puppetfile.lock
+*.iml
+.editorconfig
+.fixtures.yml
+.gitignore
+.msync.yml
+.overcommit.yml
+.pmtignore
+.rspec
+.rspec_parallel
+.rubocop.yml
+.sync.yml
+.*.sw?
+.yardoc/
+.yardopts
+Dockerfile

.rspec

@@ -0,0 +1,2 @@
+--format documentation
+--color

.rspec_parallel

@@ -0,0 +1 @@
+--format progress

.rubocop.yml

@@ -0,0 +1,3 @@
+---
+inherit_gem:
+  voxpupuli-test: rubocop.yml

.yardopts

@@ -0,0 +1,2 @@
+--markup markdown
+--output-dir docs/

Dockerfile

@@ -0,0 +1,21 @@
+FROM ruby:2.5.3
+
+WORKDIR /opt/puppet
+
+# https://github.com/puppetlabs/puppet/blob/06ad255754a38f22fb3a22c7c4f1e2ce453d01cb/lib/puppet/provider/service/runit.rb#L39
+RUN mkdir -p /etc/sv
+
+ARG PUPPET_VERSION="~> 6.0"
+ARG PARALLEL_TEST_PROCESSORS=4
+
+# Cache gems
+COPY Gemfile .
+RUN bundle install --without system_tests development release --path=${BUNDLE_PATH:-vendor/bundle}
+
+COPY . .
+
+RUN bundle install
+RUN bundle exec rake release_checks
+
+# Container should not saved
+RUN exit 1

Gemfile

@@ -0,0 +1,33 @@
+source ENV['GEM_SOURCE'] || "https://rubygems.org"
+
+group :test do
+  gem 'voxpupuli-test', '~> 2.1',  :require => false
+  gem 'coveralls',                 :require => false
+  gem 'simplecov-console',         :require => false
+end
+
+group :development do
+  gem 'guard-rake',               :require => false
+  gem 'overcommit', '>= 0.39.1',  :require => false
+end
+
+group :system_tests do
+  gem 'puppet_metadata', '~> 0.3.0',  :require => false
+  gem 'voxpupuli-acceptance',         :require => false
+end
+
+group :release do
+  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
+  gem 'puppet-strings', '>= 2.2',    :require => false
+end
+
+gem 'puppetlabs_spec_helper', '~> 2.0', :require => false
+gem 'rake', :require => false
+gem 'facter', ENV['FACTER_GEM_VERSION'], :require => false, :groups => [:test]
+
+puppetversion = ENV['PUPPET_VERSION'] || '~> 6.0'
+gem 'puppet', puppetversion, :require => false, :groups => [:test]
+
+# vim: syntax=ruby

Rakefile

@@ -0,0 +1,61 @@
+# Attempt to load voxupuli-test (which pulls in puppetlabs_spec_helper),
+# otherwise attempt to load it directly.
+begin
+  require 'voxpupuli/test/rake'
+rescue LoadError
+  require 'puppetlabs_spec_helper/rake_tasks'
+end
+
+# load optional tasks for releases
+# only available if gem group releases is installed
+begin
+  require 'voxpupuli/release/rake_tasks'
+rescue LoadError
+end
+
+desc "Run main 'test' task and report merged results to coveralls"
+task test_with_coveralls: [:test] do
+  if Dir.exist?(File.expand_path('../lib', __FILE__))
+    require 'coveralls/rake/task'
+    Coveralls::RakeTask.new
+    Rake::Task['coveralls:push'].invoke
+  else
+    puts 'Skipping reporting to coveralls.  Module has no lib dir'
+  end
+end
+
+desc 'Generate REFERENCE.md'
+task :reference, [:debug, :backtrace] do |t, args|
+  patterns = ''
+  Rake::Task['strings:generate:reference'].invoke(patterns, args[:debug], args[:backtrace])
+end
+
+begin
+  require 'github_changelog_generator/task'
+  require 'puppet_blacksmith'
+  GitHubChangelogGenerator::RakeTask.new :changelog do |config|
+    version = (Blacksmith::Modulefile.new).version
+    config.future_release = "v#{version}" if version =~ /^\d+\.\d+.\d+$/
+    config.header = "# Changelog\n\nAll notable changes to this project will be documented in this file.\nEach new release typically also includes the latest modulesync defaults.\nThese should not affect the functionality of the module."
+    config.exclude_labels = %w{duplicate question invalid wontfix wont-fix modulesync skip-changelog}
+    config.user = 'voxpupuli'
+    metadata_json = File.join(File.dirname(__FILE__), 'metadata.json')
+    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

spec/spec_helper.rb

@@ -0,0 +1,18 @@
+# This file is managed via modulesync
+# https://github.com/voxpupuli/modulesync
+# https://github.com/voxpupuli/modulesync_config
+
+# puppetlabs_spec_helper will set up coverage if the env variable is set.
+# We want to do this if lib exists and it hasn't been explicitly set.
+ENV['COVERAGE'] ||= 'yes' if Dir.exist?(File.expand_path('../../lib', __FILE__))
+
+require 'voxpupuli/test/spec_helper'
+
+if File.exist?(File.join(__dir__, 'default_module_facts.yml'))
+  facts = YAML.safe_load(File.read(File.join(__dir__, 'default_module_facts.yml')))
+  if facts
+    facts.each do |name, value|
+      add_custom_fact name.to_sym, value
+    end
+  end
+end