beaker 3.34.0 → 3.35.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 1b562d104dc7f11a75248a241139e2fe7be4d3ca
-  data.tar.gz: 6e5ac3722bae66a57d7d45fbe1193373192f46b1
+  metadata.gz: 7f5dbb3dbc5bdfbfb8b3faf9309c674fa6e07cf3
+  data.tar.gz: 35dcba5f1881fcb33c682151f9f06dab083fbe21
 SHA512:
-  metadata.gz: 4f74e6abf79b59fafff8241e7151b6ac43701da54809a972fb267c87bedb53a1e9eb8ad7ba1dab4caac60faa598d4452511cac6595ef4ec552b9c0f9dd937235
-  data.tar.gz: 43ef180c5e07267caa541bb48c091419df4d30ef0092c49a48fc9b25c33f2616b2a2f57e9ea5cfac5a8c612b82e2e90ffda91fa6e7dba4712ab6803511dacc18
+  metadata.gz: 9b64080cc40e949ca9359e27f9c3bbcd97a5d2af745f26dcb86f3807655231afd5a4e99ccebd4e33e8c4dcf308fecb25ba4ce1614859ffdff50ce1da9c8d055a
+  data.tar.gz: ac37b874e60d5b8aea0c8b4b63eb98ec2c612d78d7fbd86a37f41f2f4863d58db08c90b436bbae2165832801f5d9ceb337826d1b4779f730c0e0d5975026ce37

data/CHANGELOG.md

@@ -11,7 +11,18 @@ Tracking in this Changelog began for this project in version 3.25.0.
 If you're looking for changes from before this, refer to the project's
 git logs & PR history.
 
-# [Unreleased](https://github.com/puppetlabs/beaker/compare/3.34.0...master)
+# [Unreleased](https://github.com/puppetlabs/beaker/compare/3.35.0...master)
+
+# [3.35.0](https://github.com/puppetlabs/beaker/compare/3.34.0...3.35.0) - 2018-05-16
+
+### Fixed
+
+- Report accurate location of generated smoke test
+- Accept comma-separated tests for exec subcommand
+
+### Added
+
+- Added optional ability to use ERB in nodeset YAML files
 
 # [3.34.0](https://github.com/puppetlabs/beaker/compare/3.33.0...3.34.0) - 2018-03-26
 

data/acceptance/tests/base/external_resources_test.rb

@@ -1,10 +1,25 @@
 test_name 'External Resources Test' do
   step 'Verify EPEL resources are up and available' do
-    def epel_url_test(el_version)
+    def build_url(el_version)
       url_base = options[:epel_url]
       url_base = options[:epel_url_archive] if el_version == 5
-      url = "#{url_base}/epel-release-latest-#{el_version}.noarch.rpm"
-      curl_headers_result = default.exec(Command.new("curl -I #{url}"))
+      "#{url_base}/epel-release-latest-#{el_version}.noarch.rpm"
+    end
+
+    def epel_url_test(el_version)
+      url = build_url(el_version)
+      # -I option just asks for headers, not looking to download the package
+      curl_cmd = Command.new("curl -I #{url}")
+      host = default
+      curl_headers_result = Result.new(host, curl_cmd)
+      curl_fail_msg = "EPEL curl failed, waiting for fibonacci backoff to retry..."
+
+      repeat_fibonacci_style_for(10) do
+        curl_headers_result = host.exec(curl_cmd)
+        curl_succeeded = curl_headers_result.exit_code == 0
+        logger.info(curl_fail_msg) unless curl_succeeded
+        curl_succeeded
+      end
       assert_match(/200 OK/, curl_headers_result.stdout, "EPEL #{el_version} should be reachable at #{url}")
     end
 

data/acceptance/tests/base/host/host_test.rb

@@ -91,7 +91,7 @@ hosts.each do |host|
   # Use env_id a key to delete
   env_param3 = "#{env_id}"
   env_value3 = "#{env_id}"
-  
+
   host.add_env_var(env_param1,env_value1)
   host.add_env_var(env_param2,env_value2)
   host.add_env_var(env_param3,env_value3)

data/docs/concepts/testing_beaker_itself.md

@@ -6,7 +6,7 @@ While Beaker provides the testing harness for much of the acceptance testing tha
 
 ### Product Coverage
 
-Beaker test coverage covers the LTS PE version, currently 2016.4.0, and the latest released version of PE, currently 2016.5.0. 
+Beaker test coverage covers the LTS PE version, currently 2016.4.0, and the latest released version of PE, currently 2016.5.0.
 Since there is only a single major version of Puppet itself currently supported, beaker only run tests on the latest y-release of Puppet 4, currently 4.8.z. This currently resolves to puppet-agent 1.8.x.
 
 ### Platform Coverage
@@ -16,10 +16,10 @@ The platforms that beaker covers in its regression testing are largely what is s
 ## Test Suite Phases
 
 ### Beaker Spec
-The initial step in Beaker's pipeline is to execute spec testing with supported and future rubies; 2.2.5 and 2.3.1. 
+The initial step in Beaker's pipeline is to execute spec testing with supported and future rubies; 2.2.5 and 2.3.1.
 
-### Beaker Acceptance 
-All acceptance tests use actual OS's with beaker installed and use beaker itself to verify that its own methods and classes are working. 
+### Beaker Acceptance
+All acceptance tests use actual OS's with beaker installed and use beaker itself to verify that its own methods and classes are working.
 
 * The Base tests are tests that do not require puppet be installed on the SUT. This includes much of the DSL and host helpers.
 * The puppet tests rely on puppet being installed in the pre-suite

data/docs/concepts/ticket_process.md

@@ -11,9 +11,9 @@ stages as well.
 
 ## Administrivia
 
-- Beaker tickets live in the 
+- Beaker tickets live in the
 [BKR project](https://tickets.puppetlabs.com/issues/?jql=project%20%3D%20BKR)
-- Create a [Jira account](http://tickets.puppetlabs.com) to interact with them 
+- Create a [Jira account](http://tickets.puppetlabs.com) to interact with them
 
 ## Pre-Development States
 
@@ -39,14 +39,14 @@ person you need info from to move the ticket forward.
 
 This is the state for when a ticket has been triaged, but hasn't yet been
 estimated for work from someone on the Beaker team, or someone ready to
-take on the work. Any preliminary information needed to understand the 
+take on the work. Any preliminary information needed to understand the
 ticket (before investigation) should be gathered before this point.
 
 ### Ready for Engineering
 
 An accepted ticket that has been estimated should be put into the Ready for
-Engineering state. This does not necessarily mean that a ticket has been 
-prioritized against other Beaker work, but prioritization should occur by 
+Engineering state. This does not necessarily mean that a ticket has been
+prioritized against other Beaker work, but prioritization should occur by
 the time the issue has been picked up in a sprint.
 
 ## Development States
@@ -62,23 +62,23 @@ they're currently working on a particular issue.
 ### Ready for Merge
 
 Once a Pull Request (PR) is generated for an issue, the contributor should set
-the status to Ready for Merge. We do have a github integration setup, so if 
-you've titled your PR correctly (according to our 
-[contributor docs](/CONTRIBUTING.md)), 
+the status to Ready for Merge. We do have a github integration setup, so if
+you've titled your PR correctly (according to our
+[contributor docs](/CONTRIBUTING.md)),
 it will be linked from the JIRA ticket.
 
-In the Beaker project, we leave the assignee as the person who wrote the 
+In the Beaker project, we leave the assignee as the person who wrote the
 proposed change, so that they know that they have to keep pushing for their
 code to be merged.
 
 ### Resolved
 
-Once your PR is merged, then you can Resolve your ticket. 
+Once your PR is merged, then you can Resolve your ticket.
 
 **NOTE** that when you do this, you should set the FixedVersion to
 
     BKR.next
-    
-The reason that we do this now and not before is that we use this field to 
+
+The reason that we do this now and not before is that we use this field to
 autogenerate our release notes.  We want to make sure that we capture only
 work that is _in_ the next release, not work that's _intended_ for it.

data/docs/concepts/types_puppet_4_and_the_all_in_one_agent.md

@@ -1,6 +1,6 @@
 ## So What Are Types Anyway?
 
-Historically, Puppet Open Source and Enterprise have had different paths for different resources.  Beaker supports these configurations through the use of its `type` parameter.  The Beaker CLI exposes this parameter with the `--type` option.  
+Historically, Puppet Open Source and Enterprise have had different paths for different resources.  Beaker supports these configurations through the use of its `type` parameter.  The Beaker CLI exposes this parameter with the `--type` option.
 
 The two older types are represented by the `foss` and `pe` values.
 

data/docs/how_to/change_terminal_output_coloring.md

@@ -13,7 +13,7 @@ Changes to the default options can be made by editing the configuration file.
 Here are some examples:
 
 **Eg 1: Changing color of a particular type of message**
-Add the following to the hosts file to change the color of `success` messages to `GREEN` and `warning` messages to `YELLOW`. 
+Add the following to the hosts file to change the color of `success` messages to `GREEN` and `warning` messages to `YELLOW`.
 To get the color-code corresponding to a color, refer to: [Colors Supported by Beaker] (https://github.com/puppetlabs/beaker/blob/master/lib/beaker/logger.rb#L14-L32)
 
       HOSTS:

data/docs/how_to/confine.md

@@ -9,13 +9,13 @@ is that the **TestCase#hosts** array is modified to only contain the hosts that
 
 Full method documentation here:
 
-* [confine](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Structure#confine-instance_method) 
+* [confine](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Structure#confine-instance_method)
 
 ## How does the optional Array<Host> parameter work?
 
 However, if you pass in the optional Array<Host> to the method, the criteria will be applied to this hosts array
 (not **TestCase#hosts**). Subsequently, any of the hosts contained in **TestCase#hosts** that were not included in the Array<Host>
-passed to the method, will remain in **TestCase#hosts**. But any hosts that were filtered out by the criteria match 
+passed to the method, will remain in **TestCase#hosts**. But any hosts that were filtered out by the criteria match
 will be overwritten.
 
 Take the following example:
@@ -69,7 +69,7 @@ is being applied directly to **TestCase#hosts** (which contains all hosts).
 
 `confine :except, { :platform => 'el-7-x86_64' }`
 
-Will return two hosts (ubuntu_master and ubuntu_agent). 
+Will return two hosts (ubuntu_master and ubuntu_agent).
 
 In order to limit the hosts to only the ubuntu agent, you would need to use:
 

data/docs/how_to/debug_beaker_tests.md

@@ -67,48 +67,48 @@ Hypervisor for w2k8r2 is none
 Hypervisor for w2k3r2 is none
 Beaker::Hypervisor, found some none boxes to create
 
-pe-centos6 10:55:27$  which curl  
+pe-centos6 10:55:27$  which curl
 /usr/bin/curl
 
 pe-centos6 executed in 0.14 seconds
 
-pe-centos6 10:55:27$  which ntpdate  
+pe-centos6 10:55:27$  which ntpdate
 /usr/sbin/ntpdate
 
 pe-centos6 executed in 0.01 seconds
 
-w2k8r2 10:55:27$  which curl  
+w2k8r2 10:55:27$  which curl
 /bin/curl
 
 w2k8r2 executed in 0.42 seconds
 
-w2k3r2 10:55:27$  which curl  
+w2k3r2 10:55:27$  which curl
 /bin/curl
 
 w2k3r2 executed in 0.29 seconds
 No tests to run for suite 'pre_suite'
 Begin tests/trypry.rb
 
-pe-centos6 10:55:28$  echo hello  
+pe-centos6 10:55:28$  echo hello
 hello
 
 pe-centos6 executed in 0.01 seconds
 
-pe-centos6 10:55:28$  echo test block  
+pe-centos6 10:55:28$  echo test block
 test block
 
 pe-centos6 executed in 0.01 seconds
 block result.stdout: test block
 block result.raw_stdout: test block
 
-pe-centos6 10:55:28$  echo test block, built in functions  
+pe-centos6 10:55:28$  echo test block, built in functions
 test block, built in functions
 
 pe-centos6 executed in 0.00 seconds
 built in function stdout: test block, built in functions
 built in function stderr:
 
-pe-centos6 10:55:28$  echo no block  
+pe-centos6 10:55:28$  echo no block
 no block
 
 pe-centos6 executed in 0.00 seconds
@@ -137,7 +137,7 @@ Here's some sample console calls:
 => [pe-centos6, w2k8r2, w2k3r2]
 [2] pry(#<Beaker::TestCase>)> on hosts[1], 'echo hello'
 
-w2k8r2 10:54:11$  echo hello  
+w2k8r2 10:54:11$  echo hello
 hello
 
 w2k8r2 executed in 0.07 seconds
@@ -153,7 +153,7 @@ w2k8r2 executed in 0.07 seconds
  @stdout="hello\n">
 [3] pry(#<Beaker::TestCase>)> on hosts[1], 'ls /cygdrive/c/Documents\ and\ Settings/All\ Users/Application\ Data/'
 
-w2k8r2 10:56:15$  ls /cygdrive/c/Documents\ and\ Settings/All\ Users/Application\ Data/  
+w2k8r2 10:56:15$  ls /cygdrive/c/Documents\ and\ Settings/All\ Users/Application\ Data/
 Application Data
 Desktop
 Documents
@@ -184,7 +184,7 @@ w2k8r2 executed in 0.09 seconds
   "Application Data\nDesktop\nDocuments\nFavorites\nMicrosoft\nPackage Cache\nStart Menu\nTemplates\nVMware\nbeaker.gemspec\nntuser.pol\n">
 [4] pry(#<Beaker::TestCase>)> result = on hosts[1], 'ls /cygdrive/c/Documents\ and\ Settings/All\ Users/Application\ Data/'
 
-w2k8r2 10:56:34$  ls /cygdrive/c/Documents\ and\ Settings/All\ Users/Application\ Data/  
+w2k8r2 10:56:34$  ls /cygdrive/c/Documents\ and\ Settings/All\ Users/Application\ Data/
 Application Data
 Desktop
 Documents
@@ -239,10 +239,10 @@ Consider this example test case _test.rb_, which is going to fail:
       assert_equal(important_expected_value, actual_value, 'This product is faulty')
     end
 
-You can run this test using `beaker -t test.rb` or (to use the `run` subcommand and just run the test and bypass host provisioning etc) `beaker run -t test.rb`  
+You can run this test using `beaker -t test.rb` or (to use the `run` subcommand and just run the test and bypass host provisioning etc) `beaker run -t test.rb`
 It fails.
 
-Now try `beaker run -t test.rb --debug-errors`  
+Now try `beaker run -t test.rb --debug-errors`
 This will enter a pry console when the failure occurs.
 
     * Assert expected matches actual
@@ -250,9 +250,9 @@ This will enter a pry console when the failure occurs.
        Expected: 3
         Actual: 2>
       HINT: Use the pry 'backtrace' and 'up' commands to navigate to the test code
-    
+
     From: /home/puppet/code/beaker/lib/beaker/dsl/structure.rb @ line 51 Beaker::DSL::Structure#step:
-    
+
         38: def step step_name, &block
         39:   logger.notify "\n* #{step_name}\n"
         40:   set_current_step_name(step_name)
@@ -271,7 +271,7 @@ This will enter a pry console when the failure occurs.
         53:     logger.step_out()
         54:   end
         55: end
-    
+
     [1] pry(#<Beaker::TestCase>)>
 
 Because beaker is catching the exception, pry is showing you beaker code. But you can navigate to your own test code using the `backtrace` and `up` commands.
@@ -288,7 +288,7 @@ Because beaker is catching the exception, pry is showing you beaker code. But yo
 The arrow indicates pry is showing code at the top of the stack trace. At position #2 in the stack you can see line 5 of test.rb - this is the actual test code that failed. You can navigate there by entering the `up` command twice.
 
         From: /home/puppet/code/beaker/test.rb @ line 5 self.run_test:
-    
+
         1: test_name 'An important aspect of my product'
         2:
         3: important_expected_value = 3
@@ -297,7 +297,7 @@ The arrow indicates pry is showing code at the top of the stack trace. At positi
         6:   actual_value = 2
         7:   assert_equal(important_expected_value, actual_value, 'This product is faulty')
         8: end
-    
+
     [2] pry(#<Beaker::TestCase>)>
 
 > **NOTE:** Bear in mind that though you are navigating through your code here; pry is not rewinding code execution. When you exit pry, beaker will continue its execution from the top of the backtrace, failing the test due to the error that occurred.
@@ -307,7 +307,7 @@ From here, you can examine variables in your test. If you have hosts provisioned
 ## Defining external breakpoints with byebug
 This method is perhaps the least intuitive to use; but combines the advantages of letting you pick the line(s) of code to set breakpoints on; and being able to debug without needing to edit your test code directly. It is sometimes desirable to debug a test without changing the test's code at all; for example, if you want to compare a test at two or more different git commits, your test source needs to remain unmodified from its committed form.
 
-byebug allows you to externally define breakpoints to keep them separate from your source code. 
+byebug allows you to externally define breakpoints to keep them separate from your source code.
 
 ### Example
 Consider the following test file test.rb:

data/docs/how_to/enabling_cross_sut_access.md

@@ -13,7 +13,7 @@ To load the SSH agent and add your SSH key, run the following:
 eval `ssh-agent`
 ssh-add <SSH key file path>
 ~~~
-  
+
 A common example of where this functionality would be required for beaker developers, is in testing subcommands. There, we setup multiple SUTs that need to communicate between themselves. To run our subcommand testing to verify that you have agent forwarding setup correctly, run the following:
 
 ~~~bash

data/docs/how_to/hosts/README.md

@@ -4,5 +4,5 @@ This directory contains docs explaining any peculiarities or details of a partic
 OS's host implementation.
 
 If you don't see a file here for an OS, then it's either not yet documented
-(feel free to help us out here!), or it should conform to our normal host 
+(feel free to help us out here!), or it should conform to our normal host
 abstraction assumptions.

data/docs/how_to/hosts/cisco.md

@@ -25,7 +25,7 @@ file line that looks like this in our configuration:
       <hostname>:
         ...
         vrf: management
-    
+
 B. All Cisco hosts will also require a user to be set on the
 hosts.  This is because they don't allow ssh'ing as the root user,
 which is one of the main assumptions that Beaker operates under in

data/docs/how_to/hypervisors/README.md

@@ -36,7 +36,7 @@ Puppet and its community have made several gems that support different
 hypervisors with beaker, the reason for this is that we're looking to decrease Beaker's
 dependency footprint, and hypervisors are one of the places where we can often
 increase the load across all Beaker uses to benefit a small group that uses a
-particular hypervisor. 
+particular hypervisor.
 
 In order to offset this, we've made a listing of gems and community-supported forks
 that support other external hypervisors. Please check them out if you'd like to use

data/docs/how_to/platform_specific_tag_confines.md

@@ -18,7 +18,7 @@ hashes, where each hash specifies a platform to confine, based on the
 tags included in the test. The local options file key is
 `:platform_tag_confines`.
 
-An example local options file is included 
+An example local options file is included
 below (remember that local options files have to be readable into
 beaker as a ruby hash):
 
@@ -58,7 +58,7 @@ UI confine example like this:
 
     "ui" tests will be confined away from ubuntu-1404 hosts, because
     "TODO: We have not applied the UI tests to Ubuntu yet"
-    
+
 
 ## But Why Do We Need These?
 

data/docs/how_to/preserve_hosts.md

@@ -70,13 +70,13 @@ the directory that holds all of the log files for a particular beaker run. The
 short way to access that directory is to look into the `log/latest` path, which
 is a symlink to the actual log directory for the run.
 
-The `hosts_preserved.yml` file generated by a run differs from the original 
+The `hosts_preserved.yml` file generated by a run differs from the original
 hosts file passed into Beaker in a number of ways:
 
 - all suites are emptied
 - the host names are updated to point to the IPs (or hostnames) of the VMs since
 they exist and no longer need provisioning
-- the `provision` option is set to `false` (check 
+- the `provision` option is set to `false` (check
 [Beaker Test Run's](../tutorials/test_run.md) provisioning section for details).
 
 Beaker will also output the lines included below at the end of the run:

data/docs/how_to/rake_tasks.md

@@ -13,7 +13,7 @@ You will also need to have Beaker installed as part of your bundle.
 When you run:
 
     rake --tasks
-    
+
 from your project dir, you should see (as well as any rake tasks you have defined locally)
 
     rake beaker:test[hosts,type]  # Run Beaker Acceptance
@@ -41,9 +41,8 @@ Your options file would look something like:
 To use the more generic test task, you will need to pass in the type as the 2nd argument to the rake task:
 
     rake beaker:test[,smoke]
-    
+
 This will assume that you have created the file:
 
     acceptance/beaker-smoke.cfg
-    
-    
+

data/docs/how_to/test_arbitrary_beaker_versions.md

@@ -1,7 +1,7 @@
 # Test arbitrary beaker versions without modifying test code
 
 In order to adjust the beaker version used without commiting a change to a Gemfile,
-we at Puppet often use a method in our code that changes the dependency based on the 
+we at Puppet often use a method in our code that changes the dependency based on the
 existence of ENV variables in the shell that beaker is executing from. The code
 itself looks like this:
 
@@ -19,7 +19,7 @@ end
 
 ```
 
-Once this method definition is in place in the Gemfile, we can call it in a gem command, like 
+Once this method definition is in place in the Gemfile, we can call it in a gem command, like
 this:
 
 ```ruby
@@ -40,7 +40,7 @@ git://github.com/puppetlabs/beaker.git#master
 ```
 file://../relative/path/to/beaker
 ```
-By adjusting the shell environment that beaker is running in, we can modify what version of 
+By adjusting the shell environment that beaker is running in, we can modify what version of
 beaker is installed by bundler on your test coordinator without modifying any of the test
 code. This strategy can be used for any gem dependency, and is often used when testing
 [beaker libraries](../concepts/beaker_libraries.md) at Puppet.