diff options
| -rw-r--r-- | .gitignore | 8 | ||||
| -rw-r--r-- | .sync.yml | 9 | ||||
| -rw-r--r-- | .travis.yml | 26 | ||||
| -rw-r--r-- | CONTRIBUTING.md | 295 | ||||
| -rw-r--r-- | README.markdown | 21 | ||||
| -rw-r--r-- | lib/puppet/parser/functions/concat.rb | 6 | ||||
| -rw-r--r-- | lib/puppet/parser/functions/private.rb | 29 | ||||
| -rw-r--r-- | lib/puppet/type/file_line.rb | 3 | ||||
| -rw-r--r-- | spec/acceptance/nodesets/centos-59-x64.yml | 10 | ||||
| -rw-r--r-- | spec/acceptance/nodesets/centos-65-x64.yml | 10 | ||||
| -rw-r--r-- | spec/acceptance/nodesets/ubuntu-server-1404-x64.yml | 11 | ||||
| -rwxr-xr-x | spec/functions/concat_spec.rb | 5 | ||||
| -rwxr-xr-x | spec/functions/private_spec.rb | 55 |
13 files changed, 398 insertions, 90 deletions
@@ -1,7 +1,7 @@ pkg/ -.DS_Store -coverage/ -spec/fixtures/ Gemfile.lock +vendor/ +spec/fixtures/ +.vagrant/ .bundle/ -vendor/bundle/ +coverage/ diff --git a/.sync.yml b/.sync.yml new file mode 100644 index 0000000..21e872e --- /dev/null +++ b/.sync.yml @@ -0,0 +1,9 @@ +--- +.travis.yml: + script: "\"bundle exec rake validate && bundle exec rake lint && bundle exec rake spec SPEC_OPTS='--color --format documentation'\"" +Rakefile: + unmanaged: true +Gemfile: + unmanaged: true +spec/spec_helper.rb: + unmanaged: true diff --git a/.travis.yml b/.travis.yml index 34d8cc9..3ed1153 100644 --- a/.travis.yml +++ b/.travis.yml @@ -2,26 +2,16 @@ language: ruby bundler_args: --without development script: "bundle exec rake validate && bundle exec rake lint && bundle exec rake spec SPEC_OPTS='--color --format documentation'" -rvm: - - 1.8.7 - - 1.9.3 - - 2.0.0 - - ruby-head -env: - - PUPPET_GEM_VERSION=">= 3.0.0" matrix: fast_finish: true - allow_failures: - - rvm: 2.0.0 - - rvm: ruby-head include: - - rvm: 1.8.7 - env: PUPPET_GEM_VERSION="~> 2.7" + - rvm: 1.8.7 + env: PUPPET_GEM_VERSION="~> 2.7.0" FACTER_GEM_VERSION="~> 1.6.0" + - rvm: 1.8.7 + env: PUPPET_GEM_VERSION="~> 2.7.0" FACTER_GEM_VERSION="~> 1.7.0" + - rvm: 1.9.3 + env: PUPPET_GEM_VERSION="~> 3.0" + - rvm: 2.0.0 + env: PUPPET_GEM_VERSION="~> 3.0" notifications: email: false - webhooks: - urls: - - https://puppet-dev-community.herokuapp.com/event/travis-ci/ - on_success: always - on_failure: always - on_start: yes diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 5280da1..e128847 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,65 +1,234 @@ -# How to contribute - -Third-party patches are essential for keeping stdlib great. We simply can't -access the huge number of platforms and myriad configurations for running -stdlib. We want to keep it as easy as possible to contribute changes that -get things working in your environment. There are a few guidelines that we -need contributors to follow so that we can have a chance of keeping on -top of things. - -## Getting Started - -* Make sure you have a [Jira account](http://tickets.puppetlabs.com) -* Make sure you have a [GitHub account](https://github.com/signup/free) -* Submit a ticket for your issue, assuming one does not already exist. - * Clearly describe the issue including steps to reproduce when it is a bug. - * Make sure you fill in the earliest version that you know has the issue. -* Fork the repository on GitHub - -## Making Changes - -* Create a topic branch from where you want to base your work. - * This is usually the master branch. - * Only target release branches if you are certain your fix must be on that - branch. - * To quickly create a topic branch based on master; `git branch - fix/master/my_contribution master` then checkout the new branch with `git - checkout fix/master/my_contribution`. Please avoid working directly on the - `master` branch. -* Make commits of logical units. -* Check for unnecessary whitespace with `git diff --check` before committing. -* Make sure your commit messages are in the proper format. - -```` - (#99999) Make the example in CONTRIBUTING imperative and concrete - - Without this patch applied the example commit message in the CONTRIBUTING - document is not a concrete example. This is a problem because the - contributor is left to imagine what the commit message should look like - based on a description rather than an example. This patch fixes the - problem by making the example concrete and imperative. - - The first line is a real life imperative statement with a ticket number - from our issue tracker. The body describes the behavior without the patch, - why this is a problem, and how the patch fixes the problem when applied. -```` - -* Make sure you have added the necessary tests for your changes. -* Run _all_ the tests to assure nothing else was accidentally broken. - -## Submitting Changes - -* Sign the [Contributor License Agreement](http://links.puppetlabs.com/cla). -* Push your changes to a topic branch in your fork of the repository. -* Submit a pull request to the repository in the puppetlabs organization. -* Update your ticket to mark that you have submitted code and are ready for it to be reviewed. - * Include a link to the pull request in the ticket - -# Additional Resources - -* [More information on contributing](http://links.puppetlabs.com/contribute-to-puppet) -* [Bug tracker (Jira)](http://tickets.puppetlabs.com) -* [Contributor License Agreement](http://links.puppetlabs.com/cla) +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: + + - Sign the [Contributor License Agreement](https://cla.puppetlabs.com/) + + - Make sure you have a [GitHub account](https://github.com/join) + + - [Create a ticket](http://projects.puppetlabs.com/projects/modules/issues/new), or [watch the ticket](http://projects.puppetlabs.com/projects/modules/issues) 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. Sign the Contributor License Agreement + + Before we can accept your changes, we do need a signed Puppet + Labs Contributor License Agreement (CLA). + + You can access the CLA via the [Contributor License Agreement link](https://cla.puppetlabs.com/) + + If you have any questions about the CLA, please feel free to + contact Puppet Labs via email at cla-submissions@puppetlabs.com. + + 3. 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. + + + 4. 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://projects.puppetlabs.com/projects/puppet/wiki/Getting_Help) + +* [Writing tests](http://projects.puppetlabs.com/projects/puppet/wiki/Development_Writing_Tests) + +* [Patchwork](https://patchwork.puppetlabs.com) + +* [Contributor License Agreement](https://projects.puppetlabs.com/contributor_licenses/sign) + * [General GitHub documentation](http://help.github.com/) + * [GitHub pull request documentation](http://help.github.com/send-pull-requests/) -* #puppet-dev IRC channel on freenode.org + diff --git a/README.markdown b/README.markdown index e9ad53b..51adefe 100644 --- a/README.markdown +++ b/README.markdown @@ -725,6 +725,27 @@ Will return: ['pa','pb','pc'] - *Type*: rvalue + +private +------- +This function sets the current class or definition as private. +Calling the class or definition from outside the current module will fail. + +*Examples:* + + private() + +called in class `foo::bar` will output the following message if class is called +from outside module `foo`: + + Class foo::bar is private + +You can specify the error message you want to use as a parameter: + + private("You're not supposed to do that!") + +- *Type*: statement + range ----- When given range in the form of (start, stop) it will extrapolate a range as diff --git a/lib/puppet/parser/functions/concat.rb b/lib/puppet/parser/functions/concat.rb index 6c86382..0d35b07 100644 --- a/lib/puppet/parser/functions/concat.rb +++ b/lib/puppet/parser/functions/concat.rb @@ -28,11 +28,7 @@ Would result in: raise(Puppet::ParseError, 'concat(): Requires array to work with') end - if b.is_a?(Array) - result = a.concat(b) - else - result = a << b - end + result = a + Array(b) return result end diff --git a/lib/puppet/parser/functions/private.rb b/lib/puppet/parser/functions/private.rb new file mode 100644 index 0000000..60210d3 --- /dev/null +++ b/lib/puppet/parser/functions/private.rb @@ -0,0 +1,29 @@ +# +# private.rb +# + +module Puppet::Parser::Functions + newfunction(:private, :doc => <<-'EOS' + Sets the current class or definition as private. + Calling the class or definition from outside the current module will fail. + EOS + ) do |args| + + raise(Puppet::ParseError, "private(): Wrong number of arguments "+ + "given (#{args.size}}) for 0 or 1)") if args.size > 1 + + scope = self + if scope.lookupvar('module_name') != scope.lookupvar('caller_module_name') + message = nil + if args[0] and args[0].is_a? String + message = args[0] + else + manifest_name = scope.source.name + manifest_type = scope.source.type + message = (manifest_type.to_s == 'hostclass') ? 'Class' : 'Definition' + message += " #{manifest_name} is private" + end + raise(Puppet::ParseError, message) + end + end +end diff --git a/lib/puppet/type/file_line.rb b/lib/puppet/type/file_line.rb index 323fc4c..9dbe43c 100644 --- a/lib/puppet/type/file_line.rb +++ b/lib/puppet/type/file_line.rb @@ -21,6 +21,9 @@ Puppet::Type.newtype(:file_line) do In this example, Puppet will ensure both of the specified lines are contained in the file /etc/sudoers. + **Autorequires:** If Puppet is managing the file that will contain the line + being managed, the file_line resource will autorequire that file. + EOT ensurable do diff --git a/spec/acceptance/nodesets/centos-59-x64.yml b/spec/acceptance/nodesets/centos-59-x64.yml new file mode 100644 index 0000000..2ad90b8 --- /dev/null +++ b/spec/acceptance/nodesets/centos-59-x64.yml @@ -0,0 +1,10 @@ +HOSTS: + centos-59-x64: + roles: + - master + platform: el-5-x86_64 + box : centos-59-x64-vbox4210-nocm + box_url : http://puppet-vagrant-boxes.puppetlabs.com/centos-59-x64-vbox4210-nocm.box + hypervisor : vagrant +CONFIG: + type: git diff --git a/spec/acceptance/nodesets/centos-65-x64.yml b/spec/acceptance/nodesets/centos-65-x64.yml new file mode 100644 index 0000000..4e2cb80 --- /dev/null +++ b/spec/acceptance/nodesets/centos-65-x64.yml @@ -0,0 +1,10 @@ +HOSTS: + centos-65-x64: + roles: + - master + platform: el-6-x86_64 + box : centos-65-x64-vbox436-nocm + box_url : http://puppet-vagrant-boxes.puppetlabs.com/centos-65-x64-virtualbox-nocm.box + hypervisor : vagrant +CONFIG: + type: foss diff --git a/spec/acceptance/nodesets/ubuntu-server-1404-x64.yml b/spec/acceptance/nodesets/ubuntu-server-1404-x64.yml new file mode 100644 index 0000000..cba1cd0 --- /dev/null +++ b/spec/acceptance/nodesets/ubuntu-server-1404-x64.yml @@ -0,0 +1,11 @@ +HOSTS: + ubuntu-server-1404-x64: + roles: + - master + platform: ubuntu-14.04-amd64 + box : puppetlabs/ubuntu-14.04-64-nocm + box_url : https://vagrantcloud.com/puppetlabs/ubuntu-14.04-64-nocm + hypervisor : vagrant +CONFIG: + log_level : debug + type: git diff --git a/spec/functions/concat_spec.rb b/spec/functions/concat_spec.rb index b853b4c..49cb2ad 100755 --- a/spec/functions/concat_spec.rb +++ b/spec/functions/concat_spec.rb @@ -27,4 +27,9 @@ describe "the concat function" do expect(result).to(eq(['1','2','3',['4','5'],'6'])) end + it "should leave the original array intact" do + array_original = ['1','2','3'] + result = scope.function_concat([array_original,['4','5','6']]) + array_original.should(eq(['1','2','3'])) + end end diff --git a/spec/functions/private_spec.rb b/spec/functions/private_spec.rb new file mode 100755 index 0000000..c70759f --- /dev/null +++ b/spec/functions/private_spec.rb @@ -0,0 +1,55 @@ +#! /usr/bin/env ruby -S rspec +require 'spec_helper' + +describe Puppet::Parser::Functions.function(:private) do + let(:scope) { PuppetlabsSpec::PuppetInternals.scope } + + subject do + function_name = Puppet::Parser::Functions.function(:private) + scope.method(function_name) + end + + context "when called from inside module" do + it "should not fail" do + scope.expects(:lookupvar).with('module_name').returns('foo') + scope.expects(:lookupvar).with('caller_module_name').returns('foo') + expect { + subject.call [] + }.not_to raise_error + end + end + + context "with an explicit failure message" do + it "prints the failure message on error" do + scope.expects(:lookupvar).with('module_name').returns('foo') + scope.expects(:lookupvar).with('caller_module_name').returns('bar') + expect { + subject.call ['failure message!'] + }.to raise_error Puppet::ParseError, /failure message!/ + end + end + + context "when called from private class" do + it "should fail with a class error message" do + scope.expects(:lookupvar).with('module_name').returns('foo') + scope.expects(:lookupvar).with('caller_module_name').returns('bar') + scope.source.expects(:name).returns('foo::baz') + scope.source.expects(:type).returns('hostclass') + expect { + subject.call [] + }.to raise_error Puppet::ParseError, /Class foo::baz is private/ + end + end + + context "when called from private definition" do + it "should fail with a class error message" do + scope.expects(:lookupvar).with('module_name').returns('foo') + scope.expects(:lookupvar).with('caller_module_name').returns('bar') + scope.source.expects(:name).returns('foo::baz') + scope.source.expects(:type).returns('definition') + expect { + subject.call [] + }.to raise_error Puppet::ParseError, /Definition foo::baz is private/ + end + end +end |