vagrant-bolt 0.1.0

data/Rakefile

@@ -0,0 +1,19 @@
+# frozen_string_literal: true
+
+require 'rubygems'
+require 'bundler/setup'
+require 'rspec/core/rake_task'
+require 'rubocop/rake_task'
+
+Dir.chdir(File.expand_path(__dir__))
+
+RuboCop::RakeTask.new(:rubocop) do |t|
+  t.options = ['--display-cop-names']
+end
+
+task_dir = File.expand_path("tasks", __dir__)
+Dir["#{task_dir}/**/*.rake"].each do |task_file|
+  load task_file
+end
+
+task default: [:rubocop, :spec]

data/Vagrantfile

@@ -0,0 +1,47 @@
+require 'vagrant-bolt'
+Vagrant.configure("2") do |config|
+  config.vm.box = "alpine/alpine64"
+  config.bolt.run_as = 'root'
+
+  # Using a global bolt trigger for a plan
+  # This will fire on all machines after :up
+  config.trigger.after :up do |trigger|
+    trigger.name = "Bolt \"facts::bash\" after :up"
+    trigger.ruby do |env, machine|
+      VagrantBolt.plan("facts", env, machine)
+    end
+  end
+
+  ## Server
+  config.vm.define 'server' do |node|
+    # Machine level bolt configs
+    node.bolt.run_as = 'vagrant'
+    # Trigger bolt using a trigger
+    node.trigger.after :provision do |trigger|
+      trigger.name = "Bolt \"facts::bash\" after provision"
+      trigger.ruby do |env, machine|
+        # Sending additional config for the task
+        VagrantBolt.task("facts::bash", env, machine, host_key_check: false, verbose: true)
+      end
+    end
+  end
+
+  ## Server2
+  config.vm.define 'server2' do |node|
+    # Using the Bolt provisioner instead of a trigger
+    node.vm.provision :bolt do |bolt|
+      bolt.command = :task
+      bolt.name    = "service::linux"
+      bolt.params  = { name: "chronyd", action: "restart" }
+      bolt.nodes   = 'ALL'
+      bolt.run_as  = "root"
+    end
+    # Using a command before the machine is destroyed
+    node.trigger.before :destroy do |trigger|
+      trigger.name = "Bolt \"hostname\" after up"
+      trigger.ruby do |env, machine|
+        VagrantBolt.command("hostname", env, machine)
+      end
+    end
+  end
+end

data/acceptance/components/bolt_spec.rb

@@ -0,0 +1,98 @@
+# frozen_string_literal: true
+
+shared_examples 'provider/virtualbox' do |provider, options|
+  include_context "acceptance"
+  let(:extra_env) { options[:env_vars] }
+
+  before do
+    environment.skeleton('base')
+    assert_execute('vagrant', 'box', 'add', 'box', options[:box])
+  end
+
+  after do
+    execute('vagrant', 'destroy', '-f', log: false)
+  end
+
+  describe 'bolt provisioner' do
+    before(:each) do
+      environment.skeleton('provisioner')
+      @result = assert_execute('vagrant', 'up', "--provider=#{provider}")
+    end
+
+    it 'runs a task, plan, and command' do
+      expect(@result.exit_code).to eq(0)
+      expect(@result.stdout).to match(%r{Bolt: Running bolt command locally: \/[^\ ]+bolt task run 'facts'})
+      expect(@result.stdout).to match(%r{Bolt: Running bolt command locally: \/[^\ ]+bolt plan run 'facts'})
+      expect(@result.stdout).to match(%r{Bolt: Running bolt command locally: \/[^\ ]+bolt command run})
+      expect(@result.stdout.scan(%r{Successful on 1 node}).size).to eq(3)
+    end
+  end
+
+  describe 'bolt trigger' do
+    before(:each) do
+      environment.skeleton('trigger')
+      @result = assert_execute('vagrant', 'up', "--provider=#{provider}")
+    end
+
+    it 'runs a task, plan, and command' do
+      expect(@result.exit_code).to eq(0)
+      expect(@result.stdout).to match(%r{Bolt: Running bolt command locally: \/[^\ ]+bolt task run 'facts'})
+      expect(@result.stdout).to match(%r{Bolt: Running bolt command locally: \/[^\ ]+bolt plan run 'facts'})
+      expect(@result.stdout).to match(%r{Bolt: Running bolt command locally: \/[^\ ]+bolt command run})
+      expect(@result.stdout.scan(%r{Successful on 1 node}).size).to eq(3)
+    end
+  end
+
+  describe 'bolt command' do
+    before(:each) do
+      @result = assert_execute('vagrant', 'up', "--provider=#{provider}")
+    end
+
+    it 'runs a task, plan, and command' do
+      expect(@result.exit_code).to eq(0)
+      result = assert_execute('vagrant', 'bolt', 'task', 'run', 'facts', '-n', 'server')
+      expect(result.exit_code).to eq(0)
+      expect(result.stdout).to match(%r{Bolt: Running bolt command locally: '\/[^\ ]+bolt' 'task' 'run' 'facts'})
+      expect(result.stdout.scan(%r{Successful on 1 node}).size).to eq(1)
+      result = assert_execute('vagrant', 'bolt', 'plan', 'run', 'facts', '-n', 'server')
+      expect(result.exit_code).to eq(0)
+      expect(result.stdout).to match(%r{Bolt: Running bolt command locally: '\/[^\ ]+bolt' 'plan' 'run' 'facts'})
+      expect(result.stdout.scan(%r{Successful on 1 node}).size).to eq(1)
+      result = assert_execute('vagrant', 'bolt', 'command', 'run', 'hostname', '-n', 'server')
+      expect(result.exit_code).to eq(0)
+      expect(result.stdout).to match(%r{Bolt: Running bolt command locally: '\/[^\ ]+bolt' 'command' 'run'})
+      expect(result.stdout.scan(%r{Successful on 1 node}).size).to eq(1)
+    end
+  end
+
+  describe 'bolt advanced use cases' do
+    before(:each) do
+      environment.skeleton('advanced')
+      @result = assert_execute('vagrant', 'up', "--provider=#{provider}")
+    end
+
+    # This is a mashup of many tests combined. In an effort to cut down the time, this tests many items.
+    it 'runs bolt' do
+      # Ensure the machines came online
+      expect(@result.exit_code).to eq(0)
+      ## Allnodetest
+      # Check for root level triggers
+      result = assert_execute('vagrant', 'provision')
+      expect(result.exit_code).to eq(0)
+      # Ensure that the trigger is run on both nodes
+      expect(result.stdout.scan(%r{server[12]:\s+allnodetest}).size).to eq(4)
+      # Ensure that 'nodes = all' includes both nodes
+      expect(result.stdout).to match(%r{Bolt: Running bolt command locally: \/[^\ ]+bolt command run[^\n]+allnodetest[^\n]+server[12],server[12]})
+      # Ensure that the root level `run_as` is used
+      expect(result.stdout).to match(%r{Bolt: Running bolt command locally: \/[^\ ]+bolt command run[^\n]+allnodetest[^\n]+--run-as 'root'})
+      ## Configtest
+      # Ensure excludes overrides nodes
+      expect(result.stdout).to match(%r{Bolt: Running bolt command locally: \/[^\ ]+bolt command run[^\n]+configtest[^\n]+server2})
+      # Ensure verbose and debug flags are correctly handled
+      expect(result.stdout).to match(%r{Bolt: Running bolt command locally: \/[^\ ]+bolt command run[^\n]+configtest[^\n]+--verbose})
+      expect(result.stdout).not_to match(%r{Bolt: Running bolt command locally: \/[^\ ]+bolt command run[^\n]+configtest[^\n]+--debug})
+      # Ensure run_as override
+      expect(result.stdout).to match(%r{Bolt: Running bolt command locally: \/[^\ ]+bolt command run[^\n]+configtest[^\n]+--run-as 'vagrant'})
+    end
+  end
+end

data/acceptance/skeletons/advanced/Vagrantfile

@@ -0,0 +1,26 @@
+require 'vagrant-spec/which'
+Vagrant.configure('2') do |config|
+  config.bolt.bolt_exe = Vagrant::Spec::Which.which('bolt')
+  config.bolt.run_as = 'root'
+  config.vm.box = 'box'
+  # Run a trigger on all nodes after provision
+  config.trigger.after :provision do |trigger|
+    trigger.ruby do |env, machine|
+      VagrantBolt.command('/bin/echo "allnodetest"', env, machine, nodes: 'all')
+    end
+  end
+  config.vm.define 'server1' do |node|
+    # Provision a node testing the config options
+    node.vm.provision :bolt do |bolt|
+      bolt.command = :command
+      bolt.name    = '/bin/echo "configtest"'
+      bolt.nodes   = ['server1', 'server2']
+      bolt.excludes = ['server1']
+      bolt.verbose = true
+      bolt.debug = false
+      bolt.run_as = "vagrant"
+    end
+  end
+  config.vm.define 'server2' do |node|
+  end
+end

data/acceptance/skeletons/base/Vagrantfile

@@ -0,0 +1,11 @@
+require 'vagrant-spec/which'
+Vagrant.configure('2') do |config|
+  config.bolt.bolt_exe = Vagrant::Spec::Which.which('bolt')
+  config.vm.box = 'box'
+  config.vm.define 'server' do |node|
+    node.vm.provision :bolt do |bolt|
+      bolt.command = :task
+      bolt.name    = "facts"
+    end
+  end
+end

data/acceptance/skeletons/base/modules/facts/CHANGELOG.md

@@ -0,0 +1,26 @@
+# Change Log
+
+## 0.3.1
+### Fixed
+- Allow setting Puppet gem version via `PUPPET_GEM_VERSION` so we can use Puppet 5 to ship the module.
+
+## 0.3.0
+### Fixed
+- Task metadata specifies environment input to work around BOLT-691.
+
+### Changed
+- Stop hiding failures gathering facts in the `facts` plan.
+
+### Removed
+- `facts::retrieve` as redundant with the `facts` task when cross-platform
+tasks are supported.
+
+## 0.2.0
+### Added
+- Legacy facts added to results.
+- Improve ability of bash and ruby task to find facter executable path.
+
+## 0.1.2
+
+### Changed
+- Move facts to external module (from bolt).

data/acceptance/skeletons/base/modules/facts/CONTRIBUTING.md

@@ -0,0 +1,279 @@
+# Contributing to Puppet modules
+
+So you want to contribute to a Puppet module: Great! Below are some instructions to get you started doing
+that very thing while setting expectations around code quality as well as a few tips for making the
+process as easy as possible. 
+
+### Table of Contents
+
+1. [Getting Started](#getting-started)
+1. [Commit Checklist](#commit-checklist)
+1. [Submission](#submission)
+1. [More about commits](#more-about-commits)
+1. [Testing](#testing)
+    - [Running Tests](#running-tests)
+    - [Writing Tests](#writing-tests)
+1. [Get Help](#get-help)
+
+## Getting Started
+
+- Fork the module repository on GitHub and clone to your workspace
+
+- Make your changes!
+
+## Commit Checklist
+
+### The Basics
+
+- [x] my commit is a single logical unit of work
+
+- [x] I have checked for unnecessary whitespace with "git diff --check" 
+
+- [x] my commit does not include commented out code or unneeded files
+
+### The Content
+
+- [x] my commit includes tests for the bug I fixed or feature I added
+
+- [x] my commit includes appropriate documentation changes if it is introducing a new feature or changing existing functionality
+    
+- [x] my code passes existing test suites
+
+### The Commit Message
+
+- [x] the first line of my commit message includes:
+
+  - [x] an issue number (if applicable), e.g. "(MODULES-xxxx) This is the first line" 
+  
+  - [x] a short description (50 characters is the soft limit, excluding ticket number(s))
+
+- [x] the body of my commit message:
+
+  - [x] is meaningful
+
+  - [x] uses the imperative, present tense: "change", not "changed" or "changes"
+
+  - [x] includes motivation for the change, and contrasts its implementation with the previous behavior
+
+## Submission
+
+### Pre-requisites
+
+- Make sure you have a [GitHub account](https://github.com/join)
+
+- [Create a ticket](https://tickets.puppet.com/secure/CreateIssue!default.jspa), or [watch the ticket](https://tickets.puppet.com/browse/) you are patching for.
+
+### Push and PR
+
+- Push your changes to your fork
+
+- [Open a Pull Request](https://help.github.com/articles/creating-a-pull-request-from-a-fork/) against the repository in the puppetlabs organization
+
+## More about commits 
+
+  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](https://help.github.com/articles/creating-a-pull-request-from-a-fork/).
+
+      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 JIRA issue.
+
+      If there is a JIRA 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, and then use it to 
+install all dependencies needed for this project in the project root by running
+
+```shell
+% bundle install --path .bundle/gems
+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
+```
+
+## Running Tests
+
+With all dependencies in place and up-to-date, run the tests:
+
+### Unit Tests
+
+```shell
+% bundle exec rake spec
+```
+
+This executes all the [rspec tests](http://rspec-puppet.com/) in the directories defined [here](https://github.com/puppetlabs/puppetlabs_spec_helper/blob/699d9fbca1d2489bff1736bb254bb7b7edb32c74/lib/puppetlabs_spec_helper/rake_tasks.rb#L17) and so on. 
+rspec tests may have the same kind of dependencies as the module they are testing. Although the module defines these dependencies in its [metadata.json](./metadata.json),
+rspec tests define them in [.fixtures.yml](./fixtures.yml).
+
+### Acceptance Tests
+
+Some Puppet modules also come with acceptance tests, which use [beaker][]. These tests spin up a virtual machine under
+[VirtualBox](https://www.virtualbox.org/), controlled with [Vagrant](http://www.vagrantup.com/), to simulate scripted test
+scenarios. In order to run these, you need both Virtualbox and Vagrant installed on your system.
+
+Run the tests by issuing the following command
+
+```shell
+% bundle exec rake spec_clean
+% bundle exec 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).
+
+A specific node set can be selected by setting the `BEAKER_set` environment variable
+
+```shell
+% export BEAKER_set=spec/acceptance/nodesets/centos-7-x64
+```
+
+If using a VM pooler node set, a password must be set via `BEAKER_password`.
+
+## Writing Tests
+
+### Unit Tests
+
+When writing unit tests for Puppet, [rspec-puppet][] is your best friend. It provides tons of helper methods for testing your manifests against a 
+catalog (e.g. contain_file, contain_package, with_params, etc). It would be ridiculous to try and top rspec-puppet's [documentation][rspec-puppet_docs] 
+but here's a tiny sample:
+
+Sample manifest:
+
+```puppet
+file { "a test file":
+  ensure => present,
+  path   => "/etc/sample",
+}
+```
+
+Sample test:
+
+```ruby
+it 'does a thing' do
+  expect(subject).to contain_file("a test file").with({:path => "/etc/sample"})
+end
+```
+
+### Acceptance Tests
+
+Writing acceptance tests for Puppet involves [beaker][] and its cousin [beaker-rspec][]. A common pattern for acceptance tests is to create a test manifest, apply it
+twice to check for idempotency or errors, then run expectations.
+
+```ruby
+it 'does an end-to-end thing' do
+  pp = <<-EOF
+    file { 'a test file': 
+      ensure  => present,
+      path    => "/etc/sample",
+      content => "test string",
+    }
+    
+  apply_manifest(pp, :catch_failures => true)
+  apply_manifest(pp, :catch_changes => true)
+  
+end
+
+describe file("/etc/sample") do
+  it { is_expected.to contain "test string" }
+end
+
+```
+
+# If you have commit access to the repository
+
+Even if you have commit access to the repository, you 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 project developer that did not write the code to ensure that
+all changes go through a code review process.**
+
+The record of someone performing the merge is the record that they performed the code review. Again, this should be someone other than the author of the topic branch.
+
+# Get Help
+
+### On the web
+* [Puppet help messageboard](http://puppet.com/community/get-help)
+* [Writing tests](https://docs.puppet.com/guides/module_guides/bgtm.html#step-three-module-testing)
+* [General GitHub documentation](http://help.github.com/)
+* [GitHub pull request documentation](http://help.github.com/send-pull-requests/)
+
+### On chat
+* Slack (slack.puppet.com) #forge-modules, #puppet-dev, #windows, #voxpupuli
+* IRC (freenode) #puppet-dev, #voxpupuli
+
+
+[rspec-puppet]: http://rspec-puppet.com/
+[rspec-puppet_docs]: http://rspec-puppet.com/documentation/
+[beaker]: https://github.com/puppetlabs/beaker
+[beaker-rspec]: https://github.com/puppetlabs/beaker-rspec