puppet-retrospec 0.8.1 → 0.9.0

data/spec/fixtures/modules/stdlib/tests/has_ip_address.pp

@@ -0,0 +1,3 @@
+include stdlib
+info('has_ip_address(\'192.168.1.256\'):', has_ip_address('192.168.1.256'))
+info('has_ip_address(\'127.0.0.1\'):', has_ip_address('127.0.0.1'))

data/spec/fixtures/modules/stdlib/tests/has_ip_network.pp

@@ -0,0 +1,4 @@
+include stdlib
+info('has_ip_network(\'127.0.0.0\'):', has_ip_network('127.0.0.0'))
+info('has_ip_network(\'128.0.0.0\'):', has_ip_network('128.0.0.0'))
+

data/spec/fixtures/modules/stdlib/tests/init.pp

@@ -0,0 +1 @@
+include stdlib

data/spec/fixtures/modules/tomcat/.gitignore

@@ -0,0 +1,8 @@
+.*.sw?
+pkg
+spec/fixtures
+.rspec_system
+.vagrant
+.bundle
+vendor
+.idea

data/spec/fixtures/modules/tomcat/.puppet-lint.rc

@@ -0,0 +1,8 @@
+# Use this file to instruct puppet-lint to ignore certain checks.
+# For the complete list of checks and flags to disable them,
+# refer to <http://puppet-lint.com/checks/>.
+
+# Examples (uncomment before use):
+#--no-80chars-check
+#--no-class_inherits_from_params_class-check
+#--no-inherits_across_namespaces-check

data/spec/fixtures/modules/tomcat/.travis.yml

@@ -0,0 +1,14 @@
+branches:
+script: "bundle exec rake spec SPEC_OPTS='--format documentation'"
+bundler_args: --without development
+
+rvm:
+- 1.9.3
+- 2.0.0
+- 2.1.5
+- 2.2.0
+env:
+  matrix:
+    - PUPPET_GEM_VERSION="~> 3.2"
+    - PUPPET_GEM_VERSION="~> 3.7"
+

data/spec/fixtures/modules/tomcat/CHANGELOG.md

@@ -0,0 +1,94 @@
+##2015-06-09 - Supported Release 1.3.0
+###Summary
+
+This is a feature release, with a couple of bugfixes and readme changes.
+
+####Features
+- Update additional_attributes to support values with spaces
+- Documentation changes
+- Add a manifest for Context Containers in Tomcat configuration
+- Manage User and Roles in Realms
+- New manifests for context.xml configuration
+- Added manifest for managing Realm elements in server.xml
+- Ordering of setenv entries
+- Adds parameter for enabling Tomcat service on boot
+- Add ability to specify server_config location
+- Allow configuration of location of server.xml
+
+####Bugfixes
+- Make sure setenv entries have export
+- Test improvements
+- version pinning for acceptance tests
+
+##2014-11-11 - Supported Release 1.2.0
+###Summary
+
+This is primarily a feature release, with a couple of bugfixes for tests and metadata.
+
+####Features
+- Add `install_from_source` parameter to class `tomcat`
+- Add `purge_connectors` parameter to class `tomcat` and define `tomcat::server::connector`
+
+####Bugfixes
+- Fix dependencies to remove missing dependency warnings with the PMT
+- Use `curl -k` in the tests
+
+##2014-10-28 - Supported Release 1.1.0
+###Summary
+
+This release includes documentation and test updates, strict variable support, metadata bugs, and added support for multiple connectors with the same protocol.
+
+###Features
+- Strict variable support
+- Support multiple connectors with the same protocol
+- Update tests to not break when tomcat releases happen
+- Update README based on QA feedback
+
+###Bugfixes
+- Update stdlib requirement to 4.2.0
+- Fix illegal version range in metadata.json
+- Fix typo in README
+
+##2014-09-04 - Supported Release 1.0.1
+###Summary
+
+This is a bugfix release.
+
+###Bugfixes
+- Fix typo in tomcat::instance
+- Update acceptance tests for new tomcat releases
+
+##2014-08-27 - Supported Release 1.0.0
+###Summary
+
+This release has added support for installation from packages, improved WAR management, and updates to testing and documentation.
+
+###Features
+- Updated tomcat::setenv::entry to better support installations from package
+- Added the ability to purge auto-exploded WAR directories when removing WARs. Defaults to purging these directories
+- Added warnings for unused variables when installing from package
+- Updated acceptance tests and nodesets
+- Updated README
+
+###Deprecations
+- $tomcat::setenv::entry::base_path is being deprecated in favor of $tomcat::setenv::entry::config_file
+
+##2014-08-20 - Release 0.1.2
+###Summary
+
+This release adds compatibility information and updates the README with information on the requirement of augeas >= 1.0.0.
+
+##2014-08-14 - Release 0.1.1
+###Summary
+
+This is a bugfix release.
+
+###Bugfixes
+- Update 'warn' to correct 'warning' function.
+- Update README for use_init.
+- Test updates and fixes.
+
+##2014-08-06 - Release 0.1.0
+###Summary
+
+Initial release of the tomcat module.

data/spec/fixtures/modules/tomcat/CONTRIBUTING.md

@@ -0,0 +1,220 @@
+Checklist (and a short version for the impatient)
+=================================================
+
+  * Commits:
+
+    - 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:
+      `bundle exec rspec spec/acceptance` More information on [testing](#Testing) below
+
+    - When introducing a new feature, make sure it is properly
+      documented in the README.md
+
+  * Submission:
+
+    * Pre-requisites:
+
+      - Make sure you have a [GitHub account](https://github.com/join)
+
+      - [Create a ticket](https://tickets.puppetlabs.com/secure/CreateIssue!default.jspa), or [watch the ticket](https://tickets.puppetlabs.com/browse/) you are patching for.
+
+    * Preferred method:
+
+      - Fork the repository on GitHub.
+
+      - 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).
+
+      - Submit a pull request to the repository in the puppetlabs
+        organization.
+
+The 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.
+
+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://github.com/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/)
+

data/spec/fixtures/modules/tomcat/LICENSE

@@ -0,0 +1,15 @@
+Copyright (C) 2012 Puppet Labs Inc
+
+Puppet Labs can be contacted at: info@puppetlabs.com
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.

data/spec/fixtures/modules/tomcat/README.markdown

@@ -0,0 +1,75 @@
+# profiles 
+
+## Module development setup
+
+Install all the require gems to run test code
+```shell
+bundle install  (only need to do once)
+
+```
+## Running Tests
+
+### Unit tests
+This type of testing is fast and should be the first thing you do before comming your code.  Mistakes can be found
+in a matter of seconds vs minutes/hours.  You can test your logic in a unit test.  The downside is you need to learn
+how to write unit tests which can take some initial time getting used to.
+
+```shell
+bundle exec rake spec
+
+```
+
+### Integration Testing
+This type of testing is somewhat manual and requires the use of vagrant and a test vm that is controlled by vagrant.
+You can find the list of available test vms by running `vagrant status` in the root of the module directory.  There is 
+at lot of magic happening in the vagrantfile that makes this easy.  Windows support with this module has not been added yet.
+
+```shell
+
+$ vagrant status
+Current machine states:
+
+win2012r2                 not created (vmware_fusion)
+win2008r2                 not created (vmware_fusion)
+centos6                   running (vmware_fusion)
+```
+
+To run a test first you need to define the test code located in module_root/tests directory.  This code is nothing more
+than a bunch of puppet code that uses your manifest code.  You will be using puppet apply to run this code on the vm. 
+Have a look inside the tests directory for examples.
+
+Example test file
+```
+include profiles::default_linux
+file{'/tmp/test.txt':
+    ensure => file,
+    content => 'Hello World'
+}
+```
+
+There are a few ways to run the test code against a test vm, both of which have the same outcome.
+
+```shell
+bundle exec rake spec_prep
+VAGRANT_MANIFEST=linux.pp vagrant provision centos6
+```
+
+or use the rake command which bundles the two commands together
+
+```shell
+bundle exec rake "vagrant_up[linux.pp,centos6]"
+```
+
+### Acceptance Tests 
+Acceptance testing is sorta like combining unit testing and integration testing where it tests the code on real systems
+automatically across a wide range of operating systems.  This is an advanced topic, so yu will want to master unit and
+integration testing first before writing acceptance tests.
+
+```shell
+bundle exec rake beaker
+
+```
+
+
+## CI config doc
+https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/configuration/advanced-configuration.md