Update from voxpupuli modulesync_config

.gitignore

@@ -5,6 +5,7 @@ spec/fixtures/
 .vagrant/
 .bundle/
 coverage/
+log/
 .idea/
 *.iml
-log/
+.*.sw

.rspec

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

.rubocop.yml

@@ -0,0 +1,57 @@
+AllCops:
+ Include:
+ - ./**/*.rb
+ Exclude:
+ - vendor/**/*
+ - pkg/**/*
+ - spec/fixtures/**/*
+
+# Configuration parameters: AllowURI, URISchemes.
+Metrics/LineLength:
+ Max: 328
+
+# 'Complexity' is very relative
+Metrics/PerceivedComplexity:
+ Enabled: false
+
+# 'Complexity' is very relative
+Metrics/CyclomaticComplexity:
+ Enabled: false
+
+# 'Complexity' is very relative
+Metrics/AbcSize:
+ Enabled: false
+
+# Method length is not necessarily an indicator of code quality
+Metrics/MethodLength:
+ Enabled: false
+
+# Class length is not necessarily an indicator of code quality
+Metrics/ClassLength:
+ Enabled: false
+
+# dealbreaker:
+Style/TrailingComma:
+ Enabled: false
+Style/ClosingParenthesisIndentation:
+ Enabled: false
+
+# we still support ruby 1.8
+Style/HashSyntax:
+ Enabled: false
+
+Lint/AmbiguousRegexpLiteral:
+ Enabled: true
+Style/RegexpLiteral:
+ Enabled: true
+Style/WordArray:
+ Enabled: true
+
+# this catches the cases of using `module` for parser functions, types, or
+# providers
+Style/ClassAndModuleChildren:
+ Enabled: false
+
+Style/Documentation:
+ Description: 'Document classes and non-namespace modules.'
+ Enabled: false

.travis.yml

@@ -1,36 +1,36 @@
 ---
 sudo: false
 language: ruby
+cache: bundler
 bundler_args: --without system_tests
-script: "bundle exec rake validate && bundle exec rake lint && bundle exec rake spec SPEC_OPTS='--format documentation'"
+before_install: rm Gemfile.lock || true
+script:
+ - 'bundle exec rake $CHECK'
 matrix:
  fast_finish: true
  include:
- - rvm: 1.8.7
- env: PUPPET_GEM_VERSION="~> 3.0"
  - rvm: 1.9.3
- env: PUPPET_GEM_VERSION="~> 3.0"
+ env: PUPPET_VERSION="~> 3.0" STRICT_VARIABLES="yes" CHECK=test
+ - rvm: 2.1.7
+ env: PUPPET_VERSION="~> 3.0" STRICT_VARIABLES="yes" CHECK=test
+ - rvm: 2.1.7
+ env: PUPPET_VERSION="~> 4.0" STRICT_VARIABLES="yes" CHECK=test
+ - rvm: 2.2.3
+ env: PUPPET_VERSION="~> 4.0" STRICT_VARIABLES="yes" CHECK=test
+ - rvm: 2.2.3
+ env: PUPPET_VERSION="~> 4.0" STRICT_VARIABLES="yes" CHECK=rubocop
  - rvm: 2.1.5
- env: PUPPET_GEM_VERSION="~> 3.0"
- - rvm: 2.1.5
- env: PUPPET_GEM_VERSION="~> 3.0" FUTURE_PARSER="yes"
- - rvm: 2.1.6
- env: PUPPET_GEM_VERSION="~> 4.0" STRICT_VARIABLES="yes"
- allow_failures:
- - rvm: 2.1.6
- env: PUPPET_GEM_VERSION="~> 4.0" STRICT_VARIABLES="yes"
+ env: PUPPET_GEM_VERSION="~> 3.0" STRICT_VARIABLES="yes"
 notifications:
  email: false
-
 deploy:
  provider: puppetforge
  user: puppet
  password:
  secure: "SCQpiBB9qpZAjBRk+b9D3cSCQfYpDgHPOdOc7djfGeB5yn1UbGg7uW1zshrshb4QMLfUgvsL4LsT0CYj7ilBerghgeySF5JWuZdk05W/7Iudls4btbxdVjqtALR7p02mnk40qHTR1Tdb/j0gXW9uigU6nQU9iCP+Poa1KF6PXpk="
  on:
  tags: true
- # all_branches are required to use tags
+ # all_branches is required to use tags
  all_branches: true
  # Only publish if our main Ruby target builds
- rvm: 2.1.5
- env: PUPPET_GEM_VERSION="~> 3.0"
+ rvm: 1.9.3

CONTRIBUTING.md

@@ -1,220 +1,85 @@
-Checklist (and a short version for the impatient)
-=================================================
+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 quicker.
 
- * Commits:
 
- - Make commits of logical units.
+## Contributing
 
- - Check for unnecessary whitespace with "git diff --check" before
- committing.
+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/).
 
- - Commit using Unix line endings (check the settings around "crlf" in
- git-config(1)).
+1. Fork the repo.
 
- - Do not check in commented out code or unneeded files.
+1. Create a separate branch for your change.
 
- - 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.
+1. Run the tests. We only take pull requests with passing tests, and
+ documentation.
 
- - Associate the issue in the message. The first line should include
- the issue number in the form "(#XXXX) Rest of message".
+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.
 
- - The body should provide a meaningful commit message, which:
+1. Squash your commits down into logical components. Make sure to rebase
+ against the current master.
 
- - uses the imperative, present tense: "change", not "changed" or
- "changes".
+1. Push the branch to your fork and submit a pull request.
 
- - includes motivation for the change, and contrasts its
- implementation with the previous behavior.
+Please be prepared to repeat some of these steps as our contributors review
+your code.
 
- - Make sure that you have tests for the bug you are fixing, or
- feature you are adding.
+## Dependencies
 
- - Make sure the test suites passes after your commit:
- `bundle exec rspec spec/acceptance` More information on [testing](#Testing) below
+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).
 
- - When introducing a new feature, make sure it is properly
- documented in the README.md
+By default the tests use a baseline version of Puppet.
 
- * Submission:
+If you have Ruby 2.x or want a specific version of Puppet,
+you must set an environment variable such as:
 
- * Pre-requisites:
+ export PUPPET_VERSION="~> 4.2.0"
 
- - Make sure you have a [GitHub account](https:/join)
+Install the dependencies like so...
 
-  - [Create a ticket](https://tickets.puppetlabs.com/secure/CreateIssue!default.jspa), or [watch the ticket](https://tickets.puppetlabs.com/browse/) you are patching for.
+ bundle install
 
- * Preferred method:
+## Syntax and style
 
- - Fork the repository on GitHub.
+The test suite will run [Puppet Lint](http://puppet-lint.com/) and
+[Puppet Syntax](https:/gds-operations/puppet-syntax) to
+check various syntax and style things. You can run these locally with:
 
- - Push your changes to a topic branch in your fork of the
- repository. (the format ticket/1234-short_description_of_change is
- usually preferred for this project).
+ bundle exec rake test
 
- - Submit a pull request to the repository in the puppetlabs
- organization.
+## Running the unit tests
 
-The long version
-================
+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 your specific spec test
+you can pass it to `SPEC`:
 
- 1. Make separate commits for logically separate changes.
+  bundle exec rake spec SPEC=spec/foo_spec.rb
 
- 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.
+## Integration tests
 
- If you are going to refactor a piece of code, please do so as a
- separate commit from your feature or bug fix changes.
+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:/puppetlabs/beaker).
 
- 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.
+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:
 
- 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.
+ bundle exec rake acceptance
 
- 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.
+This will run the tests on an Ubuntu 12.04 virtual machine. You can also
+run the integration tests against Centos 6.5 with.
 
- 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.
+ RS_SET=centos-64-x64 bundle exec rake acceptances
 
- 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.
-
-Testing
-=======
-
-Getting Started
----------------
-
-Our puppet modules provide [`Gemfile`](./Gemfile)s which can tell a ruby
-package manager such as [bundler](http://bundler.io/) what Ruby packages,
-or Gems, are required to build, develop, and test this software.
-
-Please make sure you have [bundler installed](http://bundler.io/#getting-started)
-on your system, then use it to install all dependencies needed for this project,
-by running
-
-```shell
-% bundle install
-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.
-```
-
-NOTE some systems may require you to run this command with sudo.
-
-If you already have those gems installed, make sure they are up-to-date:
-
-```shell
-% bundle update
-```
-
-With all dependencies in place and up-to-date we can now run the tests:
-
-```shell
-% rake spec
-```
-
-This will execute all the [rspec tests](http://rspec-puppet.com/) tests
-under [spec/defines](./spec/defines), [spec/classes](./spec/classes),
-and so on. rspec tests may have the same kind of dependencies as the
-module they are testing. While the module defines in its [Modulefile](./Modulefile),
-rspec tests define them in [.fixtures.yml](./fixtures.yml).
-
-Some puppet modules also come with [beaker](https:/puppetlabs/beaker)
-tests. These tests spin up a virtual machine under
-[VirtualBox](https://www.virtualbox.org/)) with, controlling it with
-[Vagrant](http://www.vagrantup.com/) to actually simulate scripted test
-scenarios. In order to run these, you will need both of those tools
-installed on your system.
-
-You can run them by issuing the following command
-
-```shell
-% rake spec_clean
-% rspec spec/acceptance
-```
-
-This will now download a pre-fabricated image configured in the [default node-set](./spec/acceptance/nodesets/default.yml),
-install puppet, copy this module and install its dependencies per [spec/spec_helper_acceptance.rb](./spec/spec_helper_acceptance.rb)
-and then run all the tests under [spec/acceptance](./spec/acceptance).
-
-Writing Tests
--------------
-
-XXX getting started writing tests.
-
-If you have commit access to the repository
-===========================================
-
-Even if you have commit access to the repository, you will 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
-developer on the project (that did not write the code) to ensure that
-all changes go through a code review process.
-
-Having someone other than the author of the topic branch recorded as
-performing the merge is the record that they performed the code
-review.
-
-
-Additional Resources
-====================
-
-* [Getting additional help](http://puppetlabs.com/community/get-help)
-
-* [Writing tests](http://projects.puppetlabs.com/projects/puppet/wiki/Development_Writing_Tests)
-
-* [Patchwork](https://patchwork.puppetlabs.com)
-
-* [General GitHub documentation](http://help.github.com/)
-
-* [GitHub pull request documentation](http://help.github.com/send-pull-requests/)
+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_fies`.