beaker 3.35.0 → 3.36.0

data/docs/how_to/platform_specific_tag_confines.md

@@ -2,25 +2,15 @@
 
 ## What Are These?
 
-Typically when adding support for new platforms, a number of tests have to
-be confined away from executing on that new platform. This can be for a
-number of reasons, from partial implementation/support to tests having
-incorrect assumptions that don't work on the new platform.
+Typically when adding support for new platforms, a number of tests have to be confined away from executing on that new platform. This can be for a number of reasons, from partial implementation/support to tests having incorrect assumptions that don't work on the new platform.
 
-Platform-specific tag confines are structures created to make this workflow
-easier, & achievable in a much more low-impact and adaptable way.
+Platform-specific tag confines are structures created to make this workflow easier, & achievable in a much more low-impact and adaptable way.
 
 ## Ok, So How Do We Use Them?
 
-In the local options file (provided to the command line interface (CLI)
-using the `--options-file` parameter), you can now provide an array of
-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`.
+In the local options file (provided to the command line interface (CLI) using the `--options-file` parameter), you can now provide an array of 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
-below (remember that local options files have to be readable into
-beaker as a ruby hash):
+An example local options file is included below (remember that local options files have to be readable into beaker as a ruby hash):
 
 ```ruby
 {
@@ -43,18 +33,13 @@ beaker as a ruby hash):
 }
 ```
 
-In this case, there are two platform confines objects specified, one for
-Ubuntu 14.04, and the other for CentOS 7. These objects consist of a hash,
-filled with two entries: the `:platform` regex, and the `:tag_reason_hash`.
+In this case, there are two platform confines objects specified, one for Ubuntu 14.04, and the other for CentOS 7. These objects consist of a hash, filled with two entries: the `:platform` regex, and the `:tag_reason_hash`.
 
-The `:platform` regex is just that, a Ruby regex matching the host's
-platform string.
+The `:platform` regex is just that, a Ruby regex matching the host's platform string.
 
-The `:tag_reason_hash` is another hash that maps tags to the reason that
-tests that have this particular tag are being confined away from testing.
+The `:tag_reason_hash` is another hash that maps tags to the reason that tests that have this particular tag are being confined away from testing.
 
-Taking one of our confine examples from above, we can think of the Ubuntu
-UI confine example like this:
+Taking one of our confine examples from above, we can think of the Ubuntu 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"
@@ -62,15 +47,10 @@ UI confine example like this:
 
 ## But Why Do We Need These?
 
-Usually when we add platforms, the confining tests step is very heavy
-handed & repetitive, usually consisting of adding boilerplate confine
-calls that don't provide any explanation for why these are happening.
-This can make it hard to later know the reason for the confine, making
-it hard to know when we should be able to remove confines down the road.
+Usually when we add platforms, the confining tests step is very heavy handed & repetitive, usually consisting of adding boilerplate confine calls that don't provide any explanation for why these are happening. This can make it hard to later know the reason for the confine, making it hard to know when we should be able to remove confines down the road.
 
-This new workflow should provide a number of advantages over the previous
-one, including:
+This new workflow should provide a number of advantages over the previous one, including:
 
 1. Always reporting a reason for confining a platform
 2. Allowing these to be dynamically determined from configuration, rather
-    than needing to edit tens to hundreds of test files in-repo
+    than needing to edit tens to hundreds of test files in-repo

data/docs/how_to/preserve_hosts.md

@@ -2,40 +2,23 @@
 
 ## Motivation
 
-Often when developing acceptance tests to be run with beaker, you'll want to be
-able to quickly iterate on those tests in an already setup System Under Test
-(SUT) configuration. Beaker provides the ability to do that using its preserved
-hosts functionality.
+Often when developing acceptance tests to be run with beaker, you'll want to be able to quickly iterate on those tests in an already setup System Under Test (SUT) configuration. Beaker provides the ability to do that using its preserved hosts functionality.
 
 ## But Is This The Right Solution?
 
-Many people are of the opinion that if you have to login to a SUT, then you've
-already failed, and that the purpose of good automation is so that you don't
-ever have to do this. Beaker supports a diverse group of developers and testers,
-and we try to remain flexible and support multiple approaches to these problems.
+Many people are of the opinion that if you have to login to a SUT, then you've already failed, and that the purpose of good automation is so that you don't ever have to do this. Beaker supports a diverse group of developers and testers, and we try to remain flexible and support multiple approaches to these problems.
 
-Another approach you might take to debugging failed tests, during development or
-test runs in your Continuous Integration (CI) systems, is to archive any
-artifacts or log files from the SUTs, so that you can read them all from the
-beaker coordinator. Beaker provides a Domain-Specific Language (DSL) method to
-accomodate this workflow, called `archive_file_from`. Check out the
-[how-to article](archive_sut_files.md) on this method for details on it.
+Another approach you might take to debugging failed tests, during development or test runs in your Continuous Integration (CI) systems, is to archive any artifacts or log files from the SUTs, so that you can read them all from the beaker coordinator. Beaker provides a Domain-Specific Language (DSL) method to accomodate this workflow, called `archive_file_from`. Check out the [how-to article](archive_sut_files.md) on this method for details on it.
 
-That being said, the preserved hosts functionality is still useful, particularly
-for new development. In this case, you might not be able to necessarily tell
-what files you might need from your SUTs, and exploration might be necessary.
+That being said, the preserved hosts functionality is still useful, particularly for new development. In this case, you might not be able to necessarily tell what files you might need from your SUTs, and exploration might be necessary.
 
 ## How Do I Use It?
 
-Note that where you decide to use this option will affect its precedence. You
-can learn more about this in our
-[argument processing & precedence doc](../concepts/argument_processing_and_precedence.md).
+Note that where you decide to use this option will affect its precedence. You can learn more about this in our [argument processing & precedence doc](../concepts/argument_processing_and_precedence.md).
 
 ### Command-Line Option
 
-The primary way that this option is provided is through the command line, where
-it's represented by the `--preserved-hosts` option. It defaults to `never`, and
-if you run `beaker --help`, you'll see the range of values that can be taken:
+The primary way that this option is provided is through the command line, where it's represented by the `--preserved-hosts` option. It defaults to `never`, and if you run `beaker --help`, you'll see the range of values that can be taken:
 
     $ beaker --help
         ...
@@ -50,49 +33,25 @@ if you run `beaker --help`, you'll see the range of values that can be taken:
 
 ### Local Options or Global Config
 
-You can also provide a value for this option wherever you can provide a value
-that gets merged into beaker's global options hash. The two ways to do this are
-to provide it in a local options file, or in the global `CONFIG` section of your
-hosts file. To learn more about how to set these options, check out the
-[Options File Values](../concepts/argument_processing_and_precedence.md#options-file-values)
-and the
-[`CONFIG` Section of a Hosts File](../concepts/argument_processing_and_precedence.md#config-section-of-hosts-file)
-sections of the
-[argument processing & precedence doc](../concepts/argument_processing_and_precedence.md).
+You can also provide a value for this option wherever you can provide a value that gets merged into beaker's global options hash. The two ways to do this are to provide it in a local options file, or in the global `CONFIG` section of your hosts file. To learn more about how to set these options, check out the [Options File Values](../concepts/argument_processing_and_precedence.md#options-file-values) and the [`CONFIG` Section of a Hosts File](../concepts/argument_processing_and_precedence.md#config-section-of-hosts-file) sections of the [argument processing & precedence doc](../concepts/argument_processing_and_precedence.md).
 
-Either way, the underlying property name that you will have to set if you use
-these options is `:preserve_hosts`.
+Either way, the underlying property name that you will have to set if you use these options is `:preserve_hosts`.
 
 ## What Does It Do (In Detail)?
 
-Using the preserved hosts functionality outputs a `hosts_preserved.yml` file into
-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.
+Using the preserved hosts functionality outputs a `hosts_preserved.yml` file into 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
-hosts file passed into Beaker in a number of ways:
+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
-[Beaker Test Run's](../tutorials/test_run.md) provisioning section for details).
+- 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 [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:
 
     You can re-run commands against the already provisioned SUT(s) with:
     /.../beaker --hosts log/centos7-64mdac-ubuntu1504-64a/2016-07-18_13_42_44/hosts_preserved.yml --tests smoke_simple.rb --preserve-hosts onpass
 
-The important piece here is the hosts argument, in that it's informing you of
-where the preserved hosts file is located. Of course, until you kick off another
-beaker run, you can also reach this file with the `log/latest/hosts_preserved.yml`
-symlink, as mentioned at the beginning of this section.
+The important piece here is the hosts argument, in that it's informing you of where the preserved hosts file is located. Of course, until you kick off another beaker run, you can also reach this file with the `log/latest/hosts_preserved.yml` symlink, as mentioned at the beginning of this section.
 
 ## What Do I Do With It?
 
-For subsequent runs, if you want to set something, you'll have to pay attention
-to the precedence of your arguments, to be sure that you are overriding what is
-set in the preserved hosts file. Checkout the
-[argument processing & precedence doc](../concepts/argument_processing_and_precedence.md)
-for more details on the precedence order of options parsing.
+For subsequent runs, if you want to set something, you'll have to pay attention to the precedence of your arguments, to be sure that you are overriding what is set in the preserved hosts file. Checkout the [argument processing & precedence doc](../concepts/argument_processing_and_precedence.md) for more details on the precedence order of options parsing.

data/docs/how_to/rake_tasks.md

@@ -1,7 +1,5 @@
 # Rake test tasks for running beaker
 
-## How does it work?
-
 There are some rake tasks that you can use to run Beaker tests from your local project dir.
 
 To use them from within your own project, you will need to require the following file in your project's rakefile:
@@ -20,8 +18,7 @@ from your project dir, you should see (as well as any rake tasks you have define
     rake beaker:test:git[hosts]   # Run Beaker Git tests
     rake beaker:test:pe[hosts]    # Run Beaker PE tests
 
-The last two tasks assume that you have an options file in /acceptance named beaker-git.cfg and beaker-pe.cfg
-respectively.
+The last two tasks assume that you have an options file in `/acceptance` named `beaker-git.cfg` and `beaker-pe.cfg` respectively.
 
 Your options file would look something like:
 

data/docs/how_to/recipes.md

@@ -3,11 +3,18 @@
 Patterns for best-use solutions to (not so) common problems
 
 ## How do i set persistent environment variables on a SUT, such as PATH?
+
+```ruby
     host.add_env_var('PATH', '/opt/puppetlabs/bin:$PATH')
+```
 
 ## How do i run commands on a SUT as a non-root user?
-(warning) this should be abstracted into a beaker helper, or part of on():   BKR-168 - Beaker::DSL::Helpers needs "as" method READY FOR ENGINEERING
 
-###create the user, then su with --command:
+(warning) this should be abstracted into a beaker helper, or part of `on()`: BKR-168 - Beaker::DSL::Helpers needs "as" method READY FOR ENGINEERING
+
+Create the user, then `su` with `--command`:
+
+```ruby
     on(host, puppet("resource user #{username} ensure=present managehome-true"))
     on(host, "su #{username} --command '#{command}'")
+```

data/docs/how_to/run_in_parallel.md

@@ -1,21 +1,21 @@
 # run_in_parallel global and command options
 
 ## run_in_parallel global option
-The run_in_parallel global option is an array with the following possible values: ['configure', 'install']
-It defaults to an empty array []
-It can be set in an options file, or overriden by the BEAKER_RUN_IN_PARALLEL environment variable
-example:
 
-export BEAKER_RUN_IN_PARALLEL=configure,install
+The run_in_parallel global option is an array with the following possible values: ['configure', 'install']. It defaults to an empty array `[]`. It can be set in an options file, or overriden by the `BEAKER_RUN_IN_PARALLEL` environment variable. Example:
+
+```console
+$ export BEAKER_RUN_IN_PARALLEL=configure,install
+```
 
 Including 'configure' causes timesync to execute in parallel (if timesync=true for any host)
 
 Including 'install' causes as much of the puppet install to happen in parallel as possible.
 
 ## run_in_parallel command option
-The run_in_parallel command option is a boolean value, specifying whether to execute each iteration (usually of hosts)
-in parallel, or not.  The block_on method is the primary method accepting the run_in_parallel command option,
-however many methods that call into block_on respect it as well:
+
+The run_in_parallel command option is a boolean value, specifying whether to execute each iteration (usually of hosts) in parallel, or not.  The block_on method is the primary method accepting the run_in_parallel command option, however many methods that call into block_on respect it as well:
+
 - on
 - run_block_on
 - block_on
@@ -25,9 +25,9 @@ however many methods that call into block_on respect it as well:
 - execute_powershell_script_on
 
 ## Using InParallel in your test scripts
-In addition to the options, you can use InParallel within your test scripts as well.
 
-Examples:
+In addition to the options, you can use InParallel within your test scripts as well. Examples:
+
 ```ruby
 include InParallel
 

data/docs/how_to/ssh_agent_forwarding.md

@@ -1,26 +1,21 @@
 # How to Forward ssh(1) Agent
 
-`ssh(1)` agent forwarding can is activated in the `CONFIG` section of the hosts
-file:
+`ssh(1)` agent forwarding can is activated in the `CONFIG` section of the hosts file:
 
-~~~yaml
+```yaml
 HOSTS:
   ...
 CONFIG:
   forward_ssh_agent: true
-~~~
+```
 
-Beaker will then make the ssh agent running on the beaker coordinator available to the Systems Under Test (SUT).  There is
-a gotcha though: the agent socket file in the SUT is only available
-to the user who signed in.  If you want to access remote machine resources as
-another user, you *must* change the socket permission.
+Beaker will then make the ssh agent running on the beaker coordinator available to the Systems Under Test (SUT).  There is a gotcha though: the agent socket file in the SUT is only available to the user who signed in.  If you want to access remote machine resources as another user, you *must* change the socket permission.
 
-A dirty hack is to `chmod -R 777 /tmp/ssh-*` before changing to another user
-and relying on `$SSH_AUTH_SOCK`.
+A dirty hack is to `chmod -R 777 /tmp/ssh-*` before changing to another user and relying on `$SSH_AUTH_SOCK`.
 
 Example:
 
-~~~puppet
+```puppet
 exec { '/bin/chmod -R 777 /tmp/ssh-*':
 } ->
 vcsrepo { '/var/www/app':
@@ -28,8 +23,8 @@ vcsrepo { '/var/www/app':
   source   => 'https://example.com/git/app.git',
   user     => 'deploy'
 }
-~~~
+```
 
-## Cross SUT access
+## Cross-SUT access
 
 If you need to be able to SSH between SUTs while running Beaker acceptance tests, please refer to the [enabling cross SUT access](enabling_cross_sut_access.md) document

data/docs/how_to/ssh_connection_preference.md

@@ -2,35 +2,35 @@
 
 Setting up a SSH connection to hosts can be tricky. Beaker supports three methods to SSH to hosts:
 
-1. `ip`
-2. `vmhostname (dns name)`
-3. `hostname`
+1. `:ip`
+2. `:vmhostname` - DNS name
+3. `:hostname`
 
-Beaker tries to SSH to hosts using these methods in a particular preference (order). Default preference is mentioned above. We allow hypervisor authors and end users to provide an array of these methods that reflects their preference.
+Beaker tries to SSH to hosts using these methods in a particular preference (order). Default preference is mentioned above. We allow hypervisor authors and end users to provide an array of these methods that reflects their preference. Note that methods are identified by Ruby symbols, not strings.
 
-### Why set a preference?
+## Why set a preference?
 
 Depending upon your hypervisor, your host could have specific method that it uses to SSH better and faster than other methods. For example, hosts generated by vmpooler connects better with `vmhostname` as some change their ip adderess on restart. Therefore vmpooler hypervisor sets its connection preference to use vmhostname first.
 
-### Setting SSH connection preference at hypervisor level
+## Setting SSH connection preference at hypervisor level
 
 Hypervisor authors can set SSH connection preference. The only thing they have to do is override the `connection_preference` method set in [hypervisor.rb](https://github.com/puppetlabs/beaker/blob/master/lib/beaker/hypervisor.rb) file in their own hypervisor file.
 
 For example, `beaker-vmpooler` overriding this in [vmpooler.rb](https://github.com/puppetlabs/beaker-vmpooler/blob/master/lib/beaker/hypervisor/vmpooler.rb) file.
 
-### Setting SSH connection methods in hosts file
+## Setting SSH connection methods in hosts file
 
 End users can override the connection preference that is default or set by their hypervisor. This can be done from your hosts file. All you need to do is provide a `ssh_preference` for each host. The value of this key should be an array of the methods specified above in an order you prefer. Beaker then will attempt to SSH to the hosts in that particular order.
 
 Example of a host file:
 
-```
+```yaml
 HOSTS:
   ubuntu1604-64-1:
     hypervisor: vmpooler
     platform: ubuntu-16.04-amd64
     template: ubuntu-1604-x86_64
-    ssh_preference: ['vmhostname', 'hostname', 'ip']
+    ssh_preference: [:vmhostname, :hostname, :ip]
     roles:
     - agent
     - default
@@ -38,7 +38,7 @@ HOSTS:
     hypervisor: vmpooler
     platform: ubuntu-16.04-amd64
     template: ubuntu-1604-x86_64
-    ssh_preference: ['ip, 'vmhostname']
+    ssh_preference: [:ip, :vmhostname]
     roles:
     - agent
 CONFIG:

data/docs/how_to/test_arbitrary_beaker_versions.md

@@ -1,12 +1,8 @@
 # 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
-existence of ENV variables in the shell that beaker is executing from. The code
-itself looks like this:
+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 existence of ENV variables in the shell that beaker is executing from. The code itself looks like this:
 
 ```ruby
-
 def location_for(place, fake_version = nil)
   if place =~ /^(git[:@][^#]*)#(.*)/
     [fake_version, { :git => $1, :branch => $2, :require => false }].compact
@@ -16,11 +12,9 @@ def location_for(place, fake_version = nil)
     [place, { :require => false }]
   end
 end
-
 ```
 
-Once this method definition is in place in the Gemfile, we can call it in a gem command, like
-this:
+Once this method definition is in place in the Gemfile, we can call it in a gem command, like this:
 
 ```ruby
 
@@ -37,10 +31,9 @@ git://github.com/puppetlabs/beaker.git#master
 ```
 
 ### file locations
+
 ```
 file://../relative/path/to/beaker
 ```
-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.
+
+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.

data/docs/how_to/the_beaker_dsl.md

@@ -2,23 +2,27 @@ Beaker maintains yard documentation, which covers the [Beaker DSL](http://www.ru
 
 
 
-## Assertions ##
+## Assertions
+
 To be used for confirming the result of a test is as expected.  Beaker include all Minitest assertions, plus some custom built assertions.
 
 * [Minitest assertions](http://docs.seattlerb.org/minitest/Minitest/Assertions.html)
 * [assert_output](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Assertions#assert_output-instance_method)
 * [assert_no_match](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Assertions#assert_no_match-instance_method)
 
-## Helpers ##
+## Helpers
+
 DSL methods designed to help you interact with installed projects (like facter and puppet), with hosts (like running arbitrary commands on hosts) or interacting with the web (checking is a given URL is alive or not).
 
-### Facter ###
+### Facter
+
 DSL methods for interacting with facter.
 
 * [fact_on](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/FacterHelpers#fact_on-instance_method)
 * [fact](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/FacterHelpers#fact-instance_method)
 
-### Host ###
+### Host
+
 DSL methods for host manipulation.
 
 * [on](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/HostHelpers#on-instance_method)
@@ -45,8 +49,10 @@ DSL methods for host manipulation.
 * [create_tmpdir_on](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/HostHelpers#create_tmpdir_on-instance_method)
 * [echo_on](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/HostHelpers#echo_on-instance_method)
 
-### Puppet ###
+### Puppet
+
 DSL methods for interacting with puppet.
+
 * [puppet_user](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/PuppetHelpers#puppet_user-instance_method)
 * [puppet_group](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/PuppetHelpers#puppet_group-instance_method)
 * [with_puppet_running_on](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/PuppetHelpers#with_puppet_running_on-instance_method)
@@ -78,13 +84,15 @@ DSL methods for interacting with puppet.
 * [sign_certificate](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/PuppetHelpers#sign_certificate-instance_method)
 * [create_tmpdir_for_user](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/PuppetHelpers#create_tmpdir_for_user-instance_method)
 
-### TK ###
+### TK
+
 Convenience methods for TrapperKeeper configuration.
 
 * [modify_tk_config](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/TkHelpers#modify_tk_config-instance_method)
 * [read_tk_config_string](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/TkHelpers#read_tk_config_string-instance_method)
 
-### Web ###
+### Web
+
 Helpers for web actions.
 
 * [port_open_within?](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/WebHelpers#port_open_within?-instance_method)
@@ -92,7 +100,8 @@ Helpers for web actions.
 * [fetch_http_file](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/WebHelpers#fetch_http_file-instance_method)
 * [fetch_http_dir](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/WebHelpers#fetch_http_dir-instance_method)
 
-### Test ###
+### Test
+
 DSL methods for setting information about the current test.
 
 * [current_test_name](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/TestHelpers#current_test_name-instance_method)
@@ -102,11 +111,14 @@ DSL methods for setting information about the current test.
 * [set_current_test_filename](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/TestHelpers#set_current_test_filename-instance_method)
 * [set_current_step_name](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/TestHelpers#set_current_step_name-instance_method)
 
-## Install Utilities ##
+## Install Utilities
+
 DSL methods for installing PuppetLabs projects.
 
-### EZBake ###
+### EZBake
+
 EZBake convenience methods.
+
 * [install_from_ezbake](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/EzbakeUtils#install_from_ezbake-instance_method)
 * [install_termini_from_ezbake](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/EzbakeUtils#install_termini_from_ezbake-instance_method)
 * [ezbake_dev_build](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/EzbakeUtils#ezbake_dev_build-instance_method)
@@ -122,7 +134,8 @@ EZBake convenience methods.
 * [ezbake_installsh](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/EzbakeUtils#ezbake_installsh-instance_method)
 * [conditionally_clone](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/EzbakeUtils#conditionally_clone-instance_method)
 
-### AIO ###
+### AIO
+
 Agent-only installation utilities.
 
 * [add_platform_aio_defaults](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/AIODefaults#add_platform_aio_defaults-instance_method)
@@ -130,7 +143,8 @@ Agent-only installation utilities.
 * [remove_platform_aio_defaults](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/AIODefaults#remove_platform_aio_defaults-instance_method)
 * [remove_aio_defaults_on](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/AIODefaults#remove_aio_defaults_on-instance_method)
 
-### FOSS ###
+### FOSS
+
 DSL methods for installing FOSS PuppetLabs projects.
 
 * [add_platform_foss_defaults](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/FOSSDefaults#add_platform_foss_defaults-instance_method)
@@ -167,7 +181,8 @@ DSL methods for installing FOSS PuppetLabs projects.
 * [install_puppet_agent_pe_promoted_repo_on](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/FOSSUtils#install_puppet_agent_pe_promoted_repo_on-instance_method)
 * [install_cert_on_windows](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/FOSSUtils#install_cert_on_windows-instance_method)
 
-### PE ###
+### PE
+
 DSL methods for installing Puppet Enterprise.
 
 * [add_platform_pe_defaults](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/PeDefaults#add_platform_pe_defaults-instance_method)
@@ -193,7 +208,8 @@ DSL methods for installing Puppet Enterprise.
 * [install_higgs](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/PeUtils#install_higgs-instance_method)
 * [fetch_and_push_pe](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/PeUtils#fetch_and_push_pe-instance_method)
 
-### Puppet ###
+### Puppet
+
 DSL methods that can be used for both FOSS/PE puppet installations.
 
 * [normalize_type](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/PuppetUtils#normalize_type-instance_method)
@@ -204,7 +220,8 @@ DSL methods that can be used for both FOSS/PE puppet installations.
 * [configure_type_defaults_on](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/PuppetUtils#configure_type_defaults_on-instance_method)
 * [remove_defaults_on](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/PuppetUtils#remove_defaults_on-instance_method)
 
-### Windows ###
+### Windows
+
 DSL convenience methods for installing packages on Windows SUTs.
 
 * [get_temp_path](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/WindowsUtils#get_temp_path-instance_method)
@@ -212,7 +229,8 @@ DSL convenience methods for installing packages on Windows SUTs.
 * [create_install_msi_batch_on](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/WindowsUtils#create_install_msi_batch_on-instance_method)
 * [install_msi_on](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/WindowsUtils#install_msi_on-instance_method)
 
-### Module ###
+### Module
+
 DSL methods for installing puppet modules.
 
 * [install_dev_puppet_module_on](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/ModuleUtils#install_dev_puppet_module_on-instance_method)
@@ -226,7 +244,8 @@ DSL methods for installing puppet modules.
 * [split_author_modulename](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/ModuleUtils#split_author_modulename-instance_method)
 * [build_ignore_list](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/ModuleUtils#build_ignore_list-instance_method)
 
-## Outcomes ##
+## Outcomes
+
 Methods that indicate how the given test completed (fail, pass, skip or pending).
 
 * [fail_test](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Outcomes#fail_test-instance_method)
@@ -235,12 +254,14 @@ Methods that indicate how the given test completed (fail, pass, skip or pending)
 * [skip_test](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Outcomes#skip_test-instance_method)
 * [formatted_message](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Outcomes#formatted_message-instance_method)
 
-## Patterns ##
+## Patterns
+
 Shared methods used as building blocks of other DSL methods.
 
 * [block_on](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Patterns#block_on-instance_method)
 
-## Roles ##
+## Roles
+
 DSL methods for accessing hosts of various roles.
 
 * [agents](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Roles#agents-instance_method)
@@ -260,7 +281,8 @@ DSL methods for accessing hosts of various roles.
 * [find_only_one](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Roles#find_only_one-instance_method)
 * [find_at_most_one](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Roles#find_at_most_one-instance_method)
 
-## Structure ##
+## Structure
+
 DSL methods that describe and define how a test is executed.
 
 * [step](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Structure#step-instance_method)
@@ -273,7 +295,8 @@ DSL methods that describe and define how a test is executed.
 * [select_hosts](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Structure#select_hosts-instance_method)
 * [inspect_host](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Structure#inspect_host-instance_method)
 
-## Wrappers ##
+## Wrappers
+
 Wrappers around commonly used commands.
 
 * [facter](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Wrappers#facter-instance_method)