puppet-retrospec 0.12.1 → 0.12.2

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

@@ -1,3 +0,0 @@
-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

@@ -1,4 +0,0 @@
-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

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

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

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

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

@@ -1,8 +0,0 @@
-# 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

@@ -1,14 +0,0 @@
-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

@@ -1,94 +0,0 @@
-##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

@@ -1,220 +0,0 @@
-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

@@ -1,15 +0,0 @@
-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

@@ -1,75 +0,0 @@
-# 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