beaker 3.35.0 → 3.36.0

data/docs/tutorials/lets_write_a_test.md

@@ -1,6 +1,7 @@
 ## The Task
 
 We will write a test to check if a package (specifically HTTPD) is installed and running. To do this we will write two files:
+
 1. `install.rb` - This file will install the package and start the service
 2. `mytest.rb` - This file will have our core tests that checks if the package is installed and running
 
@@ -18,7 +19,10 @@ What needs to happen in this test:
   * Test HTTPD service is running
 
 ## Create a host configuration file
+
+```console
     $ beaker-hostgenerator redhat7-64 > redhat7-64.yaml
+```
 
 This command will generate a host file for our system under test (SUT). It will use vmpooler as hypervisor for the host. Please check out [this](https://github.com/puppetlabs/beaker/tree/master/docs/how_to/hypervisors) doc to learn more about hypervisors for beaker.
 
@@ -81,8 +85,11 @@ end
 ```
 
 ## Run it!
+
 You can now run this with
 
-    beaker --host redhat7-64ma.yaml --pre-suite install.rb --tests mytest.rb
+```console
+    $ beaker --host redhat7-64ma.yaml --pre-suite install.rb --tests mytest.rb
+```
 
 Next up you may want to look at the [Beaker test for a module](../how_to/write_a_beaker_test_for_a_module.md) page.

data/docs/tutorials/quick_start_rake_tasks.md

@@ -2,49 +2,52 @@
 
 We have developed some rake tasks to help new Beaker users get up and running quickly with writing and running tests.
 
-
 ## Pre-requisites
 
 * You will need to have already completed the Beaker installation tutorial - [Beaker Installation](installation.md)
-
-* Hypervisors are services that provision SUTs for Beaker. We have made two available in this quick start guide to allow you to get up 
-and running. See the docs on how to setup [Vmpooler](https://github.com/puppetlabs/beaker-vmpooler/blob/master/vmpooler.md) and [Vagrant](https://github.com/puppetlabs/beaker-vagrant/blob/master/docs/vagrant.md).
-
+* Hypervisors are services that provision SUTs for Beaker. We have made two available in this quick start guide to allow you to get up and running. See the docs on how to setup [Vmpooler](https://github.com/puppetlabs/beaker-vmpooler/blob/master/vmpooler.md) and [Vagrant](https://github.com/puppetlabs/beaker-vagrant/blob/master/docs/vagrant.md).
 
 ## How to use them
 
 To use the tasks, you need to put the following line at the top of your project's rake file:
 
+```rake
     require 'beaker/tasks/quick_start'
+```
 
 To check that you have access to the quickstart tasks from your project, run:
 
+```console
     rake --tasks
-    
+```
+
 You should see them listed along with any rake tasks you have defined in your local project rakefile:
 
+```rake
     rake beaker_quickstart:gen_hosts[hypervisor]  # Generate Default Beaker Host Config File, valid options are: vmpooler or vagrant
     rake beaker_quickstart:gen_pre_suite           # Generate Default Pre-Suite
     rake beaker_quickstart:gen_smoke_test          # Generate Default Smoke Test
-    rake beaker_quickstart:run_test[hypervisor]   # Run Default Smoke Test, after generating default host config and test files, valid 
+    rake beaker_quickstart:run_test[hypervisor]   # Run Default Smoke Test, after generating default host config and test files, valid
     options are: vmpooler or vagrant
-
+```
 
 ## Tasks
 
 ### Hypervisor Argument
 
-Some of the tasks below take a 'hypervisor' argument that you can pass either 'vmpooler' or 'vagrant' to. If you leave it empty, the 
-task will default to using 'vagrant'.
+Some of the tasks below take a 'hypervisor' argument that you can pass either 'vmpooler' or 'vagrant' to. If you leave it empty, the task will default to using 'vagrant'.
 
 Example:
 
-    rake beaker_quickstart:gen_hosts[vmpooler]
+```console
+    $ rake beaker_quickstart:gen_hosts[vmpooler]
+```
 
 If you have the zsh shell then you will need to escape the square brackets:
 
+```console
     rake beaker_quickstart:gen_hosts\[vmpooler\]
-    
+```
 
 ### Generate tasks
 
@@ -58,23 +61,24 @@ These tasks are standalone and can be run independently from each other to gener
 
 To run:
 
-    rake beaker_quickstart:gen_hosts[hypervisor]
+```console
+    $ rake beaker_quickstart:gen_hosts[hypervisor]
+```
 
 The gen_hosts task will create a file 'default_hypervisor_hosts.yaml' in acceptance/config.
 
-If the file already exists, it will not be overwritten. This will allow you to play around with the config yourself, either by manually 
-editing the file or by using beaker-hostgenerator to generate a new hosts config.
-
+If the file already exists, it will not be overwritten. This will allow you to play around with the config yourself, either by manually editing the file or by using beaker-hostgenerator to generate a new hosts config.
 
 Vmpooler file (redhat 7 master and agent):
 
+```yaml
     ---
     HOSTS:
       redhat7-64-1:
-        pe_dir: 
-        pe_ver: 
-        pe_upgrade_dir: 
-        pe_upgrade_ver: 
+        pe_dir:
+        pe_ver:
+        pe_upgrade_dir:
+        pe_upgrade_ver:
         hypervisor: vmpooler
         platform: el-7-x86_64
         template: redhat-7-x86_64
@@ -86,10 +90,10 @@ Vmpooler file (redhat 7 master and agent):
         - classifier
         - default
       redhat7-64-2:
-        pe_dir: 
-        pe_ver: 
-        pe_upgrade_dir: 
-        pe_upgrade_ver: 
+        pe_dir:
+        pe_ver:
+        pe_upgrade_dir:
+        pe_upgrade_ver:
         hypervisor: vmpooler
         platform: el-7-x86_64
         template: redhat-7-x86_64
@@ -100,18 +104,18 @@ Vmpooler file (redhat 7 master and agent):
       nfs_server: none
       consoleport: 443
       pooling_api: http://vmpooler.delivery.puppetlabs.net/
-    
-
+```
 
 Vagrant file (ubuntu 14 master and agent):
 
+```yaml
     ---
     HOSTS:
       ubuntu1404-64-1:
-        pe_dir: 
-        pe_ver: 
-        pe_upgrade_dir: 
-        pe_upgrade_ver: 
+        pe_dir:
+        pe_ver:
+        pe_upgrade_dir:
+        pe_upgrade_ver:
         platform: ubuntu-14.04-amd64
         hypervisor: vagrant
         roles:
@@ -122,10 +126,10 @@ Vagrant file (ubuntu 14 master and agent):
         - classifier
         - default
       ubuntu1404-64-2:
-        pe_dir: 
-        pe_ver: 
-        pe_upgrade_dir: 
-        pe_upgrade_ver: 
+        pe_dir:
+        pe_ver:
+        pe_upgrade_dir:
+        pe_upgrade_ver:
         platform: ubuntu-14.04-amd64
         hypervisor: vagrant
         roles:
@@ -136,44 +140,41 @@ Vagrant file (ubuntu 14 master and agent):
       consoleport: 443
       box_url: https://vagrantcloud.com/puppetlabs/boxes/ubuntu-14.04-64-nocm
       box: puppetlabs/ubuntu-14.04-64-nocm
-
+```
 
 For more info on host generation and what these configs represent see - [Creating A Test Environment](creating_a_test_environment.md)
 
-
-### gen_pre_suite
+### `gen_pre_suite`
 
 To run:
 
-    rake beaker_quickstart:gen_pre_suite
-    
-This task will generate a default Beaker pre-suite file.
+```console
+    $ rake beaker_quickstart:gen_pre_suite
+```
 
-The gen_pre-suite task will create a file 'default_pre_suite.rb' in acceptance/setup.
-
-If the file already exists, it will not be overwritten. This will allow you to edit the pre_suite file yourself if required.
+This task will generate a default Beaker pre-suite file. The gen_pre-suite task will create a file 'default_pre_suite.rb' in acceptance/setup. If the file already exists, it will not be overwritten. This will allow you to edit the pre_suite file yourself if required.
 
 pre_suite file:
 
+```ruby
     install_puppet
-  
-See the [Test Suites doc](test_suites.md) in this directory for more information on pre-suites.
+```
 
+See the [Test Suites doc](test_suites.md) in this directory for more information on pre-suites.
 
-### gen_smoke_test
+### `gen_smoke_test`
 
 To run:
 
+```console
     rake beaker_quickstart:gen_smoke_test
-    
-This task will generate a default Beaker smoke test file.
-
-The gen_smoke_test task will create a file 'default_smoke_test.rb' in acceptance/tests.
+```
 
-If the file already exists, it will not be overwritten. This will allow you to edit the test file yourself if required.
+This task will generate a default Beaker smoke test file. The gen_smoke_test task will create a file 'default_smoke_test.rb' in acceptance/tests. If the file already exists, it will not be overwritten. This will allow you to edit the test file yourself if required.
 
 smoke test file:
 
+```ruby
     test_name 'puppet install smoketest' do
       step 'puppet install smoketest: verify \'puppet help\' can be successfully called on
       all hosts' do
@@ -182,29 +183,29 @@ smoke test file:
             end
       end
     end
-  
+```
+
 This smoke test will check that Puppet has been successfully installed on the hosts.
 
 For more information on the Beaker dsl methods available to you in your tests see - [Beaker dsl](../how_to/the_beaker_dsl.md)
 
-
 ### Run task
 
-The beaker_quickstart:run_test task will run all the above tasks in sequential order, to generate a hosts file, pre-suite file, smoke 
-test and then use these files to perform a Beaker test run. If the files already exist (see below for further info on file names and 
-location) then they will not be overwritten.
- 
+The beaker_quickstart:run_test task will run all the above tasks in sequential order, to generate a hosts file, pre-suite file, smoke test and then use these files to perform a Beaker test run. If the files already exist (see below for further info on file names and location) then they will not be overwritten.
 
 #### run_test
 
 To run:
-  
-    rake beaker_quickstart:run_test[hypervisor]
-    
+
+```console
+    $ rake beaker_quickstart:run_test[hypervisor]
+```
+
 This task will run the above 3 tasks in sequential order and then execute a Beaker test run using all 3 files.
 
-    beaker --hosts acceptance/config/default_vmpooler_hosts.yaml --pre-suite acceptance/setup/default_pre_suite.rb --tests 
-    acceptance/tests/default_smoke_test.rb
+```console
+    $ beaker --hosts acceptance/config/default_vmpooler_hosts.yaml --pre-suite acceptance/setup/default_pre_suite.rb --tests acceptance/tests/default_smoke_test.rb
+```
 
 You will end up with provisioned hosts with puppet installed and a test check executed to verify that puppet was installed.
 

data/docs/tutorials/subcommands.md

@@ -1,55 +1,42 @@
 # Using Subcommands
 
-The document gives an overview of the subcommands that Beaker supports and
-describes how to use them.
+The document gives an overview of the subcommands that Beaker supports and describes how to use them.
 
 ## Why Subcommands?
 
-Subcommands are designed to make test development and iteration simpler by
-separating out all of the phases of a Beaker [test run](test_run.md)*. Instead
-of requiring the entirety of your Beaker execution in one command, subcommands
-allow you to execute each phase independently. This allows for faster feedback
-for potential failures and better control for iterating over actual test
-development.
-
-Most subcommands pass through flags to the Beaker options. For instance, you can
-pass through `--hosts` to the `init` subcommand and it will parse the `--hosts`
-argument as if you were executing a Beaker run*. Please review the
-subcommand specific help for further information. You can see the help for a
-specific subcommand by running `beaker help SUBCOMMAND`.
-
-*Please note that in this document, a Beaker `run` is standard beaker invocation
-without any subcommands.
+Subcommands are designed to make test development and iteration simpler by separating out all of the phases of a Beaker [test run](test_run.md)*. Instead of requiring the entirety of your Beaker execution in one command, subcommands allow you to execute each phase independently. This allows for faster feedback for potential failures and better control for iterating over actual test development.
+
+Most subcommands pass through flags to the Beaker options. For instance, you can pass through `--hosts` to the `init` subcommand and it will parse the `--hosts` argument as if you were executing a Beaker run*. Please review the subcommand specific help for further information. You can see the help for a specific subcommand by running `beaker help SUBCOMMAND`.
+
+Please note that in this document, a Beaker `run` is standard beaker invocation without any subcommands.
+
 ## Available Subcommands
 
 ### beaker init
-Initializes the required `.beaker/` configuration folder. This folder contains a
-`subcommand_options.yaml` file that is user-facing; altering this file will
-alter the options for subcommand execution.
+
+Initializes the required `.beaker/` configuration folder. This folder contains a `subcommand_options.yaml` file that is user-facing; altering this file will alter the options for subcommand execution.
 
 ### beaker provision
-Provisions hosts defined in your `subcommand_options file`. You can pass the
-`--hosts` flag here to override any hosts provided there.
+
+Provisions hosts defined in your `subcommand_options file`. You can pass the `--hosts` flag here to override any hosts provided there.
 
 ### beaker exec
-Run a single file, directory, or Beaker suite. If supplied a file or directory,
-that resource will be run in the context of the `tests` suite; if supplied a
-Beaker suite, then just that suite will run. If no resource is supplied, then
-this command executes the suites as they are defined in the configuration in the
-`subcommand_options.yaml`.
+
+Run a single file, directory, or Beaker suite. If supplied a file or directory, that resource will be run in the context of the `tests` suite; if supplied a Beaker suite, then just that suite will run. If no resource is supplied, then this command executes the suites as they are defined in the configuration in the `subcommand_options.yaml`.
 
 ### beaker destroy
+
 Execute this command to deprovision your systems under test(SUTs).
 
 ## Basic workflow
 
-```
-beaker init -h hosts_file -o options_file --keyfile ssh_key --pre-suite ./setup/pre-suit/my_presuite.rb
-beaker provision
+```console
+$ beaker init -h hosts_file -o options_file --keyfile ssh_key --pre-suite ./setup/pre-suit/my_presuite.rb
+$ beaker provision
 # Note: do not pass in hosts file, or use the '-t' flag! Just the file
 # or directory. Do not pass GO. Do not collect $200.
-beaker exec ./tests/my_test.rb
+$ beaker exec ./tests/my_test.rb
 # Repeating the above command as needed
 # When you're done testing using the VM that Beaker provisioned
-beaker destroy
+$ beaker destroy
 ```

data/docs/tutorials/test_run.md

@@ -1,23 +1,21 @@
 # Beaker Test Runs
 
-A Beaker test run consists of two primary phases: an SUT provision phase and a
-suite execution phase. After suite execution, Beaker defaults to cleaning up and
-destroying the SUTs. Leave SUTs running with the `--preserve-hosts` flag.
+A Beaker test run consists of two primary phases: an SUT provision phase and a suite execution phase. After suite execution, Beaker defaults to cleaning up and destroying the SUTs. Leave SUTs running with the `--preserve-hosts` flag.
 
+## Provisioning
 
-* **Provision**
-  * Using supported hypervisors provision SUTs for testing on
-  * Do any initial configuration to ensure that the SUTs can communicate with beaker and each other
-  * skip with `--no-provision`
-  * Provisioning also runs some basic setup on the SUTs
-    * Validation
-      * Check the SUTs for necessary packages (curl, ntpdate)
-      * skip with `--no-validate`
-    * Configuration
-      * Do any post-provisioning configuration to the SUTs
-      * skip with `--no-configure`
+* Using supported hypervisors, provision SUTs for testing on
+* Do any initial configuration to ensure that the SUTs can communicate with beaker and each other
+* skip with `--no-provision`
+* Provisioning also runs some basic setup on the SUTs
+  * Validation
+    * Check the SUTs for necessary packages (curl, ntpdate)
+    * skip with `--no-validate`
+  * Configuration
+    * Do any post-provisioning configuration to the SUTs
+    * skip with `--no-configure`
 
+## Execution
 
-* **Execution**
-  * Execute the files specified in each of the suites; for further documentation,
+* Execute the files specified in each of the suites; for further documentation,
   please refer to [Test Suites & Failure Modes](test_suites.md)

data/docs/tutorials/test_suites.md

@@ -1,83 +1,54 @@
 # Test Suites & Failure Modes
 
-Beaker test suites correspond to test suites in most testing frameworks,
-being containers for tests or pre- or post-testing files to execute.
+Beaker test suites correspond to test suites in most testing frameworks, being containers for tests or pre- or post-testing files to execute.
 
-There are two main ways that you specify which test suites a particular
-file belongs in. The first way is to use the Beaker command line interface
-(CLI) arguments. These are specified in runtime order below:
+There are two main ways that you specify which test suites a particular file belongs in. The first way is to use the Beaker command line interface (CLI) arguments. These are specified in runtime order below:
 
     --pre-suite
     —-tests
     —-post-suite
     —-pre-cleanup
 
-If you’d like to find out more information about these arguments, or how
-exactly you pass the specified files to each suite, execute `beaker —-help`
-at the CLI.
+If you’d like to find out more information about these arguments, or how exactly you pass the specified files to each suite, execute `beaker —-help` at the CLI.
 
-The second way is to provide suite arguments through config files. There
-are two places that you can provide this info:
+The second way is to provide suite arguments through config files. There are two places that you can provide this info:
 
 1. The `CONFIG` section of a hosts file.
 2. A local options file passed through the `--options-file` CLI argument.
 
-Either way, the keys for the arguments needed are listed below, respective
-to the arguments listed above:
+Either way, the keys for the arguments needed are listed below, respective to the arguments listed above:
 
     :pre_suite
     :tests
     :post_suite
     :pre_cleanup
 
-*Note* that one difference between the two methods is that if you provide the
-options via the CLI, we support various input methods such as specifying
-individual files vs paths to folders. The second option (providing keys to
-config files) only works if each file is fully specified. Beaker will not
-find all files in a directory in the second case, that expansion is only done
-on the CLI inputs.
+*Note* that one difference between the two methods is that if you provide the options via the CLI, we support various input methods such as specifying individual files vs paths to folders. The second option (providing keys to config files) only works if each file is fully specified. Beaker will not find all files in a directory in the second case, that expansion is only done on the CLI inputs.
 
 # Suite Details, & Failure Mode Behavior
 
-This section is to explain the particulars of any suite, and any warnings or
-notes about using them, including how they behave in Beaker’s different
-failure modes.
+This section is to explain the particulars of any suite, and any warnings or notes about using them, including how they behave in Beaker’s different failure modes.
 
 ## Pre-Suite
 
-The pre-suite is for setting up the Systems Under Test (SUTs) for the testing
-suite. No surprises here, usually these files are filled with the setup and
-installation code needed to verify that the operating assumptions of the
-software being tested are true.
+The pre-suite is for setting up the Systems Under Test (SUTs) for the testing suite. No surprises here, usually these files are filled with the setup and installation code needed to verify that the operating assumptions of the software being tested are true.
 
-Pre-suites, since they’re supposed to contain just setup code, will fail-fast
-and the entire Beaker run will be abandoned if setup fails, since testing
-assumes that setup has succeeded.
+Pre-suites, since they’re supposed to contain just setup code, will fail-fast and the entire Beaker run will be abandoned if setup fails, since testing assumes that setup has succeeded.
 
 ## Tests
 
-Time to actually test! This suite contains the test files that you would
-like to verify new code with.
+Time to actually test! This suite contains the test files that you would like to verify new code with.
 
 The test suite behaves according to the global fail-mode setting.
 
 ## Post-Suite
 
-Usually the post-suite is used to clean up any fixtures that your tests might
-have poisoned, collect any log files that you’d like to later review, and
-to get any resources from the SUTs before they are cleaned up / deleted.
+Usually the post-suite is used to clean up any fixtures that your tests might have poisoned, collect any log files that you’d like to later review, and to get any resources from the SUTs before they are cleaned up / deleted.
 
-The post-suite only runs if the fail-mode is set to slow, which it is by
-default. Fast fail-mode will skip this suite, so that you can get feedback
-quicker, and you can potentially check out the system in the state exactly
-that it failed in.
+The post-suite only runs if the fail-mode is set to slow, which it is by default. Fast fail-mode will skip this suite, so that you can get feedback quicker, and you can potentially check out the system in the state exactly that it failed in.
 
 ## Pre-cleanup
 
-The pre-cleanup suite is for tasks that you’d like to run at the end of your
-tests, regardless of Beaker’s fail-mode. You can think of this behaving as a
-`finally` block at the end of a `try-rescue` one.
+The pre-cleanup suite is for tasks that you’d like to run at the end of your tests, regardless of Beaker’s fail-mode. You can think of this behaving as a `finally` block at the end of a `try-rescue` one.
 
-The pre-cleanup suite falls back to the global fail-mode setting, which
-defaults to slow, meaning it will run all tests regardless of any early
-failures.
+The pre-cleanup suite falls back to the global fail-mode setting, which defaults to slow, meaning it will run all tests regardless of any early failures.