beaker 3.35.0 → 3.36.0

data/acceptance/tests/base/dsl/helpers/host_helpers/curl_on_test.rb

@@ -3,10 +3,10 @@ require "helpers/test_helper"
 # construct an appropriate local file URL for curl testing
 def host_local_url(host, path)
   if host.is_cygwin?
-    "file://#{path.gsub('/', '\\\\\\\\')}"
-  else
-    "file://#{path}"
+    path_result = on(host, "cygpath #{path}")
+    path = path_result.raw_output.chomp
   end
+  "file://#{path}"
 end
 
 test_name "dsl::helpers::host_helpers #curl_on" do

data/beaker.gemspec

@@ -22,7 +22,7 @@ Gem::Specification.new do |s|
   # Testing dependencies
   s.add_development_dependency 'rspec', '~> 3.0'
   s.add_development_dependency 'rspec-its'
-  s.add_development_dependency 'fakefs', '~> 0.6'
+  s.add_development_dependency 'fakefs', '~> 0.6', '< 0.14.0'
   s.add_development_dependency 'simplecov'
   s.add_development_dependency 'rake', '~> 10.0'
 

data/docs/README.md

@@ -4,21 +4,14 @@ Documentation for Beaker can be found in this repository in [the docs/ folder]()
 
 ## Table of Contents
 
-- [Tutorials](tutorials) take you by the hand through the steps to setup a
-beaker run. Start here if you’re new to Beaker or test development.
-- [Concepts](concepts) discuss key topics and concepts at a fairly high
-level and provide useful background information and explanation.
-- [Rubydocs](http://rubydoc.info/github/puppetlabs/beaker/frames) contains the
-technical reference for APIs and other aspects of Beaker. They describe how it
-works and how to use it but assume that you have a basic understanding of key concepts.
-- [How-to guides](how_to) are recipes. They guide you through the steps
-involved in addressing key problems and use-cases. They are more advanced than
-tutorials and assume some knowledge of how Beaker works.
+- [Tutorials](tutorials) take you by the hand through the steps to setup a beaker run. Start here if you’re new to Beaker or test development.
+- [Concepts](concepts) discuss key topics and concepts at a fairly high level and provide useful background information and explanation.
+- [Rubydocs](http://rubydoc.info/github/puppetlabs/beaker/frames) contains the technical reference for APIs and other aspects of Beaker. They describe how it works and how to use it but assume that you have a basic understanding of key concepts.
+- [How-to guides](how_to) are recipes. They guide you through the steps involved in addressing key problems and use-cases. They are more advanced than tutorials and assume some knowledge of how Beaker works.
 
 ## Other Resources
 
-In addition to the overview above, which matches Beaker's main README docs section,
-this doc's README has some links to other outside resources:
+In addition to the overview above, which matches Beaker's main README docs section, this doc's README has some links to other outside resources:
 
 * [Latest Gem Release Notes](https://github.com/puppetlabs/beaker/blob/master/HISTORY.md#LATEST)
 * [Video: Beaker 101 talk at PDXPUG, May 2014](https://www.youtube.com/watch?v=cSyJXTYFXFg)

data/docs/concepts/beaker_libraries.md

@@ -1,6 +1,6 @@
 # Beaker Libraries
-Engineering at Puppet Labs has written several libraries that extends the functionality provided
-by Beaker.
+
+Engineering at Puppet Labs has written several libraries that extends the functionality provided by Beaker.
 
 To learn how to create beaker libraries, see the [Beaker-Template](https://github.com/puppetlabs/beaker-template/blob/master/README.md) documentation.
 

data/docs/concepts/glossary.md

@@ -0,0 +1,11 @@
+# Glossary
+
+Most terms used in Beaker documentation should be common. The following documents project jargon which may otherwise be confusing.
+
+## Coordinator
+
+The Coordinator is the system on which Beaker itself is run. In many environments this will be a local host, typically a developer's primary machine. Used instead of Master to avoid confusion (see [Roles](/docs/concepts/roles_what_are_they.md)).
+
+## System Under Test
+
+A System Under Test (SUT) is one of the systems which is the subject of testing with Beaker. Contrast the [Beaker Coordinator](#coordinator).

data/docs/concepts/style_guide.md

@@ -2,31 +2,16 @@
 
 ## Scope of this guide
 
-The purpose of this guide is to provide definitions for best practices when
-writing Beaker tests, both syntactically and stylistically. This guide will
-define and provide examples for preferred test layout and conventions. Common
-patterns that are recommended as well as patterns that should be avoided will be
-described.
-
-No style manual can cover every possible circumstance. When a judgement call
-becomes necessary, keep in mind the following general ideas:
-
-1. **Readability matters**. If you have to choose between two equally effective
-alternatives, pick the more readable one. This is, of course, subjective, but if
-you can read your own code three months from now, that's a great start. Don't be
-clever over readable, unless you have a documented purpose. Use object oriented
-programming when things get complex and
-[DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).
-2. **Inherit upstream conventions**. Beaker is still ruby, so use the
-[ruby community style guide](https://github.com/bbatsov/ruby-style-guide). When
-not called out here, use the ruby style guide.
+The purpose of this guide is to provide definitions for best practices when writing Beaker tests, both syntactically and stylistically. This guide will define and provide examples for preferred test layout and conventions. Common patterns that are recommended as well as patterns that should be avoided will be described.
+
+No style manual can cover every possible circumstance. When a judgement call becomes necessary, keep in mind the following general ideas:
+
+1. **Readability matters**. If you have to choose between two equally effective alternatives, pick the more readable one. This is, of course, subjective, but if you can read your own code three months from now, that's a great start. Don't be clever over readable, unless you have a documented purpose. Use object oriented programming when things get complex and [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).
+2. **Inherit upstream conventions**. Beaker is still ruby, so use the [ruby community style guide](https://github.com/bbatsov/ruby-style-guide). When not called out here, use the ruby style guide.
 
 ## Test Naming
 
-Tests should test what they say they test. Test names, both the name of the test
-file and the value given to the
-[`test_name`](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Structure#test_name-instance_method)
-function, should provide an accurate indication about the purpose of the test.
+Tests should test what they say they test. Test names, both the name of the test file and the value given to the [`test_name`](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Structure#test_name-instance_method) function, should provide an accurate indication about the purpose of the test.
 
 The `test_name` function should be the first line in the Beaker test file.
 
@@ -38,17 +23,9 @@ test_name "file resource: set default modes" do
 
 ## Structure Methods Should Use Explicit Blocks
 
-These methods aid in self-documenting your tests, including indention in the
-logs. If you don't use explicit blocks, beaker does not know how to properly
-indent your test's output.
+These methods aid in self-documenting your tests, including indention in the logs. If you don't use explicit blocks, beaker does not know how to properly indent your test's output.
 
-The most common
-[structure methods](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Structure)
-are
-[`#test_name`](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Structure#test_name-instance_method),
-[`#step`](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Structure#step-instance_method),
-and
-[`#teardown`](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Structure#teardown-instance_method).
+The most common [structure methods](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Structure) are [`#test_name`](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Structure#test_name-instance_method), [`#step`](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Structure#step-instance_method), and [`#teardown`](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Structure#teardown-instance_method).
 
 **Good:**
 ```ruby
@@ -67,17 +44,11 @@ on(host, "echo 'do this thang'")
 - Return the state of the system to the way it was prior to test execution
 - Put the teardown as early in the test as possible
 
-Teardowns must be used to return the system to the state it was in prior to the
-execution or attempted execution of the test. Beaker will gather all teardowns
-encountered throughout the execution path of the test. These teardowns will all
-be executed when the test exits, even if the test exits early due to a failure
-or error.
+Teardowns must be used to return the system to the state it was in prior to the execution or attempted execution of the test. Beaker will gather all teardowns encountered throughout the execution path of the test. These teardowns will all be executed when the test exits, even if the test exits early due to a failure or error.
 
 ### Place Teardowns Early
 
-Teardowns can be placed anywhere in the test file or its helpers. The preferred
-style is to have a teardown step near the beginning of the test file to show the
-reader that the system state will be restored.
+Teardowns can be placed anywhere in the test file or its helpers. The preferred style is to have a teardown step near the beginning of the test file to show the reader that the system state will be restored.
 
 **Good:**
 ```ruby
@@ -93,25 +64,13 @@ test_name 'The source attribute' do
 end
 ```
 
-Teardowns are at the mercy of the scoping of the variables necessary to perform
-the restoration of the system. This fact means that additional teardown steps
-will need to be added within the scope necessary to do their job. Effort should
-be taken to make the teardown steps prominent and readable so that it can be
-confirmed, via the logs, that the system has been restored.
+Teardowns are at the mercy of the scoping of the variables necessary to perform the restoration of the system. This fact means that additional teardown steps will need to be added within the scope necessary to do their job. Effort should be taken to make the teardown steps prominent and readable so that it can be confirmed, via the logs, that the system has been restored.
 
-Teardown steps registered outside of tests should use
-[`#step`](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Structure#step-instance_method)
-to document and log what they are doing.
+Teardown steps registered outside of tests should use [`#step`](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Structure#step-instance_method) to document and log what they are doing.
 
 ## Acceptable Exit Codes
 
-When using the Beaker
-[`on`](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/HostHelpers#on-instance_method)
-method, the default setting is that only an exit code of 0 (zero) will not
-trigger an error. When other exit codes are acceptable, the
-`:acceptable_exit_codes` key with an array of exit codes should be passed in the
-options hash to `#on`. If 0 (zero) is the only acceptable exit code, then the
-`:acceptable_exit_codes` symbol must not be used.
+When using the Beaker [`on`](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/HostHelpers#on-instance_method) method, the default setting is that only an exit code of 0 (zero) will not trigger an error. When other exit codes are acceptable, the `:acceptable_exit_codes` key with an array of exit codes should be passed in the options hash to `#on`. If 0 (zero) is the only acceptable exit code, then the `:acceptable_exit_codes` symbol must not be used.
 
 **Good:**
 
@@ -132,13 +91,9 @@ on(host, "rm #{file_to_rm}", :acceptable_exit_codes => [0,1])
 on(host, "rm #{file_to_rm}", :accept_all_exit_codes => true)
 ```
 
-In the last case, when any exit code is allowed, one must follow-up with a valid
-assertion test.
+In the last case, when any exit code is allowed, one must follow-up with a valid assertion test.
 
-If an exit_code outside of 0 is expected, one must use acceptable_exit_codes so
-the test will fail on the proper assertion and not error at that command.  Allow
-only the minimum expected set of exit codes unless coverage is provided by
-subsequent assertions.
+If an exit_code outside of 0 is expected, one must use acceptable_exit_codes so the test will fail on the proper assertion and not error at that command.  Allow only the minimum expected set of exit codes unless coverage is provided by subsequent assertions.
 
 ## Test Outcomes
 
@@ -146,10 +101,7 @@ When to use each, and how to format the message:
 
 ### Expecting Failure
 
-If your tests are failing due to an "expected failure", you should wrap your
-failing assertion in an
-[`expect_failure`](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Structure#expect_failure-instance_method)
-block with an explanatory logging message:
+If your tests are failing due to an "expected failure", you should wrap your failing assertion in an [`expect_failure`](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Structure#expect_failure-instance_method) block with an explanatory logging message:
 
 ```ruby
 expect_failure('expected to fail due to PE-1234') do
@@ -157,9 +109,7 @@ expect_failure('expected to fail due to PE-1234') do
 end
 ```
 
-Note that `expect_failure` will only trigger from failed assertions. It won't
-take care of failed host or `on` commands. To deal with expected failure from an
-`on` invocation, you'd want something more like this:
+Note that `expect_failure` will only trigger from failed assertions. It won't take care of failed host or `on` commands. To deal with expected failure from an `on` invocation, you'd want something more like this:
 
 ```ruby
 on(blah, 'blah', :allow_all_exit_codes => true) do |result|
@@ -171,26 +121,15 @@ end
 
 ### `fail_test`, `pass_test`, & `skip_test`
 
-These can be used anywhere in a test to exit early. A
-[`skip_test`](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Outcomes#fail_test-instance_method)
-between two assertions, for instance, will run the first assertion, raise an
-exception for `skip_test`, run teardown, and then exit as we expect. The same is
-true for
-[fail_test](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Outcomes#fail_test-instance_method).
+These can be used anywhere in a test to exit early. A [`skip_test`](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Outcomes#fail_test-instance_method) between two assertions, for instance, will run the first assertion, raise an exception for `skip_test`, run teardown, and then exit as we expect. The same is true for [fail_test](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Outcomes#fail_test-instance_method).
 
-[`pass_test`](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Outcomes#fail_test-instance_method)
-is typically not required. When the end of a test is reached without causing an
-error (due to bad test code execution, or an unhandled exit code or exception)
-or failure (due to assertions), then it passes.
+[`pass_test`](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Outcomes#fail_test-instance_method) is typically not required. When the end of a test is reached without causing an error (due to bad test code execution, or an unhandled exit code or exception) or failure (due to assertions), then it passes.
 
-`pass_test` can be used in a situation where one knows a test has passed before
-the end of a test under certain circumstances, such as during a loop that has
-not yet completed.
+`pass_test` can be used in a situation where one knows a test has passed before the end of a test under certain circumstances, such as during a loop that has not yet completed.
 
 ### Skipping Tests
 
-Skipping tests can be used, for instance, when they are temporarily failing or
-not yet complete.
+Skipping tests can be used, for instance, when they are temporarily failing or not yet complete.
 
 **Good:**
 ```ruby
@@ -203,14 +142,8 @@ confine :to, :platform => 'solaris:pending'
 
 ## Confining
 
-Another way that you can skip or manipulate tests is by confining them to apply
-to a subset of the SUTs available for testing. Confining is a complex topic, and
-one we don't have the length to get into in the style guide. For an explanation
-of confining, as well as the best practices in using it, check out our
-[confine doc](../how_to/confine.md).
+Another way that you can skip or manipulate tests is by confining them to apply to a subset of the SUTs available for testing. Confining is a complex topic, and one we don't have the length to get into in the style guide. For an explanation of confining, as well as the best practices in using it, check out our [confine doc](../how_to/confine.md).
 
 ## Assertions
 
-Always include a _unique_ error message in your assertion statement. Use strict
-asserts whenever possible (e.g. assert_equal, assert_match.
-[More info](http://danwin.com/2013/03/ruby-minitest-cheat-sheet/)).
+Always include a _unique_ error message in your assertion statement. Use strict asserts whenever possible (e.g. assert_equal, assert_match. [More info](http://danwin.com/2013/03/ruby-minitest-cheat-sheet/)).

data/docs/concepts/test_tagging.md

@@ -1,19 +1,13 @@
 ## What is This?
 
-Beaker test tagging allows you to add tags to tests (using the
-[`tag` DSL method](http://www.rubydoc.info/github/puppetlabs/beaker/master/Beaker/DSL/TestTagging#tag-instance_method)),
-so that you can include or exclude a specific subset of the tests given for use
-in this run.  Why would you want to use this?  Here are some examples of what
-you can do with this functionality:
+Beaker test tagging allows you to add tags to tests (using the [`tag` DSL method](http://www.rubydoc.info/github/puppetlabs/beaker/master/Beaker/DSL/TestTagging#tag-instance_method)), so that you can include or exclude a specific subset of the tests given for use in this run.  Why would you want to use this?  Here are some examples of what you can do with this functionality:
 
 - Run groups of tests separately from the same testing codebase
 - Declare different actions that should be taken when a test fails
 - Make new tests go through a provisional process before being considered solid tests
 
 ## How Tagging Works
-
-Add tags to a Beaker test at the beginning, like you would if you were using
-confine.  Things to stay aware of:
+ Add tags to a Beaker test at the beginning, like you would if you were using confine.  Things to stay aware of:
 
 - A test that is not executed due to a tag will be considered a ‘skipped’ test
 - Tags are free form strings and will not be subjected to any correctness testing
@@ -53,8 +47,7 @@ Preferred style no-block example:
 
 Beaker will raise an error if `--test-tag-and` & `--test-tag-exclude` contain the same tag, however.
 
-Beaker will also raise an error if you use both `--test-tag-or` & `--test-tag-and`, because
-it won't be able to determine which order they should be used in.
+Beaker will also raise an error if you use both `--test-tag-or` & `--test-tag-and`, because it won't be able to determine which order they should be used in.
 
 ## CLI Examples
 

data/docs/concepts/testing_beaker_itself.md

@@ -6,8 +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.
-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.
+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,9 +15,11 @@ 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.
 
 ### 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.

data/docs/concepts/ticket_process.md

@@ -1,75 +1,49 @@
-This doc is here to explain the lifecycle of a Beaker ticket.  If you have any
-questions about the workflow of a Beaker ticket, or the stage that it's in, you
-should be able to answer them here.  If not, then please let QE know, and we'll
-work to answer your question and update this doc, so that we can do this better
-going forward.
+# Ticket Process
 
-Note that a typical Beaker ticket goes through these states. They can sometimes
-go in order, but on average, they loop around through the various stages,
-can cycle a number of times before becoming resolved, and will sometimes skip
-stages as well.
+This doc is here to explain the lifecycle of a Beaker ticket.  If you have any questions about the workflow of a Beaker ticket, or the stage that it's in, you should be able to answer them here.  If not, then please let QE know, and we'll work to answer your question and update this doc, so that we can do this better going forward.
+
+Note that a typical Beaker ticket goes through these states. They can sometimes go in order, but on average, they loop around through the various stages, can cycle a number of times before becoming resolved, and will sometimes skip stages as well.
 
 ## Administrivia
 
-- Beaker tickets live in the
-[BKR project](https://tickets.puppetlabs.com/issues/?jql=project%20%3D%20BKR)
+- 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
 
 ## Pre-Development States
 
-These are the states that a Beaker ticket goes through before it is picked up for
-development. Note that this is only for work done by the Beaker team. If there
-is something you'd like to contribute to, we would appreciate that you go
-through the development states for tracking purposes, but you can skip directly
-to the "In Progress" state if you're going to work on a ticket.
+These are the states that a Beaker ticket goes through before it is picked up for development. Note that this is only for work done by the Beaker team. If there is something you'd like to contribute to, we would appreciate that you go through the development states for tracking purposes, but you can skip directly to the "In Progress" state if you're going to work on a ticket.
 
 ### Open
 
-The state for newly filed issues. These have not been triaged, and are
-waiting to be looked at by the team.
+The state for newly filed issues. These have not been triaged, and are waiting to be looked at by the team.
 
 ### Needs Information
 
-The state for blocked issues. These can be blocked by another issue (please link
-that issue from the ticket if that's the case), or they can be blocked on info
-needed from another party.  If this is the case, please assign the ticket to the
-person you need info from to move the ticket forward.
+The state for blocked issues. These can be blocked by another issue (please link that issue from the ticket if that's the case), or they can be blocked on info needed from another party.  If this is the case, please assign the ticket to the person you need info from to move the ticket forward.
 
 ### Accepted
 
-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
-ticket (before investigation) should be gathered before this point.
+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 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
-the time the issue has been picked up in a sprint.
+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 the time the issue has been picked up in a sprint.
 
 ## Development States
 
-Once you're ready to pick up a ticket & work on it, then it should go through
-these states.
+Once you're ready to pick up a ticket & work on it, then it should go through these states.
 
 ### In Progress
 
-This state is set aside for a Beaker contributor to let others know that
-they're currently working on a particular issue.
+This state is set aside for a Beaker contributor to let others know that 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)),
-it will be linked from the JIRA ticket.
+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)), it will be linked from the JIRA ticket.
+
+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.
 
-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.
+A team member will review the PR. If changes are required, they will be communicated in the PR discussion on GitHub.
 
 ### Resolved
 
@@ -79,6 +53,4 @@ Once your PR is merged, then you can Resolve your ticket.
 
     BKR.next
 
-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.
+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/how_to/archive_sut_files.md

@@ -1,49 +1,23 @@
 # How to Archive Files from the Systems Under Test (SUTs)
 
-Oftentimes when you're dealing with beaker test development or troubleshooting
-a failed acceptance test, you'll need to get information from a SUT. The
-traditional way that we've advocated getting information from these machines is
-to use our [preserved hosts functionality](preserve_hosts.md).
+Oftentimes when you're dealing with beaker test development or troubleshooting a failed acceptance test, you'll need to get information from a SUT. The traditional way that we've advocated getting information from these machines is to use our [preserved hosts functionality](preserve_hosts.md).
 
-If you're preserving hosts just to SSH in and look at log files, however, this
-can be a tedious exercise. Why not just bring the log files to you on the
-beaker coordinator? This doc explains exactly how to do that using our
-`archive_file_from` Domain-Specific Language (DSL) method
-([method rubydocs](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/HostHelpers#archive_file_from-instance_method)).
+If you're preserving hosts just to SSH in and look at log files, however, this can be a tedious exercise. Why not just bring the log files to you on the beaker coordinator? This doc explains exactly how to do that using our `archive_file_from` Domain-Specific Language (DSL) method ([method rubydocs](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/HostHelpers#archive_file_from-instance_method)).
 
 # How Do I Use This?
 
-`archive_file_from` is a part of the beaker DSL, so it's available in all test
-suites. Just call it from your tests, and it'll execute, pulling any particular
-file you need off your SUTs, and dropping it on your beaker coordinator's
-file system.
+`archive_file_from` is a part of the beaker DSL, so it's available in all test suites. Just call it from your tests, and it'll execute, pulling any particular file you need off your SUTs, and dropping it on your beaker coordinator's file system.
 
-A common example of a post-suite step to archive files that were created during
-a particular test is included in the Rubydocs, referenced above. Path details,
-and details of all method arguments are documented there as well. Check it out,
-and with the right use, you won't need to preserve hosts at all to debug any
-test failures.
+A common example of a post-suite step to archive files that were created during a particular test is included in the Rubydocs, referenced above. Path details, and details of all method arguments are documented there as well. Check it out, and with the right use, you won't need to preserve hosts at all to debug any test failures.
 
 # Challenges
 
 ## Conditionally Saving Files From SUTs
 
-One thing that people tend to want from this functionality is to only archive
-files from SUTs when a beaker run has failed. At this point, beaker does not
-have access to other suites from a current one. This means that in practice,
-a post-suite (where one would typically put archiving and other post-processes)
-will not be able to archive files ONLY IF the test suite has had any failures
-or errors.
+One thing that people tend to want from this functionality is to only archive files from SUTs when a beaker run has failed. At this point, beaker does not have access to other suites from a current one. This means that in practice, a post-suite (where one would typically put archiving and other post-processes) will not be able to archive files ONLY IF the test suite has had any failures or errors.
 
-Our suggestion to get the functionality required would be to have beaker always
-archive the appropriate files in the post-suite of your tests, but then only
-have Jenkins (or your job running system, whatever that may be) conditionally
-take them from the beaker coordinator to whatever external archive system you
-rely on for later analysis. This can both get you the files that you need from
-the SUTs and save on space, as only files that need analysis will be kept.
+Our suggestion to get the functionality required would be to have beaker always archive the appropriate files in the post-suite of your tests, but then only have Jenkins (or your job running system, whatever that may be) conditionally take them from the beaker coordinator to whatever external archive system you rely on for later analysis. This can both get you the files that you need from the SUTs and save on space, as only files that need analysis will be kept.
 
 # When Did This Come Out?
 
-`archive_file_from` was originally added to the DSL in beaker
-[2.48.0](https://github.com/puppetlabs/beaker/releases/tag/2.48.0), released on
-[July 27, 2016](https://github.com/puppetlabs/beaker/blob/master/HISTORY.md#2480---27-jul-2016-47d3aa18).
+`archive_file_from` was originally added to the DSL in beaker [2.48.0](https://github.com/puppetlabs/beaker/releases/tag/2.48.0), released on [July 27, 2016](https://github.com/puppetlabs/beaker/blob/master/HISTORY.md#2480---27-jul-2016-47d3aa18).