Update packer sections

website/source/docs/enterprise/packer/artifacts/creating-amis.html.md

@@ -1,6 +1,6 @@
 ---
 layout: "enterprise"
-page_title: "Creating AMI Artifacts"
+page_title: "Creating AMIs - Packer Artifacts - Terraform Enterprise"
 sidebar_current: "docs-enterprise-packerartifacts-amis"
 description: |-
   Creating AMI artifacts with Terraform Enterprise.
@@ -8,33 +8,38 @@ description: |-
 
 # Creating AMI Artifacts with Terraform Enterprise
 
-In an immutable infrastructure workflow, it's important to version and store full images (artifacts)
+In an immutable infrastructure workflow, it's important to version and store
-to be deployed. This section covers storing [AWS AMI](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html)
+full images (artifacts) to be deployed. This section covers storing [AWS
-images in Terraform Enterprise to be queried and used later.
+AMI](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) images in
+Terraform Enterprise to be queried and used later.
 
-Note the actual AMI does _not get stored_. Terraform Enterprise
+Note the actual AMI does _not get stored_. Terraform Enterprise simply keeps the
-simply keeps the AMI ID as a reference to the target image. Tools
+AMI ID as a reference to the target image. Tools like Terraform can then use
-like Terraform can then use this in a deploy.
+this in a deploy.
 
 ### Steps
 
 If you run Packer in Terraform Enterprise, the following will happen after a [push](/docs/enterprise/packer/builds/starting.html):
 
-1. Terraform Enterprise will run `packer build` against your template in our infrastructure.
+1. Terraform Enterprise will run `packer build` against your template in our
-This spins up an AWS instance in your account and provisions it with
+infrastructure. This spins up an AWS instance in your account and provisions it
- any specified provisioners
+with any specified provisioners
-2. Packer stops the instance and stores the result as an AMI in AWS
+
-under your account. This then returns an ID (the artifact) that it passes to the post-processor
+2. Packer stops the instance and stores the result as an AMI in AWS under your
-3. The post-processor creates and uploads the new artifact version with the
+account. This then returns an ID (the artifact) that it passes to the
-ID in Terraform Enterprise of the type `amazon.image` for use later
+post-processor
+
+3. The post-processor creates and uploads the new artifact version with the ID
+in Terraform Enterprise of the type `amazon.image` for use later
 
 ### Example
 
 Below is a complete example Packer template that starts an AWS instance.
 
-    {
+```json
+{
   "push": {
-        "name": "%{DEFAULT_USERNAME}/frontend"
+    "name": "my-username/frontend"
   },
   "provisioners": [],
   "builders": [
@@ -52,9 +57,9 @@ Below is a complete example Packer template that starts an AWS instance.
   "post-processors": [
     {
       "type": "atlas",
-          "artifact": "%{DEFAULT_USERNAME}/web-server",
+      "artifact": "my-username/web-server",
       "artifact_type": "amazon.image"
     }
   ]
-    }
+}
-
+```

website/source/docs/enterprise/packer/artifacts/creating-vagrant-boxes.html.md

@@ -1,6 +1,6 @@
 ---
 layout: "enterprise"
-page_title: "Creating Vagrant Artifacts"
+page_title: "Creating Vagrant Boxes - Packer Artifacts - Terraform Enterprise"
 sidebar_current: "docs-enterprise-packerartifacts-vagrant"
 description: |-
   Creating Vagrant artifacts with Terraform Enterprise.
@@ -8,37 +8,42 @@ description: |-
 
 # Creating Vagrant Boxes with Packer
 
-We recommend using Packer to create boxes, as is it is fully repeatable and keeps a strong
+We recommend using Packer to create boxes, as is it is fully repeatable and
-history of changes within Terraform Enterprise.
+keeps a strong history of changes within Terraform Enterprise.
 
 ## Getting Started
 
-Using Packer requires more up front effort, but the repeatable and
+Using Packer requires more up front effort, but the repeatable and automated
-automated builds will end any manual management of boxes. Additionally,
+builds will end any manual management of boxes. Additionally, all boxes will be
-all boxes will be stored and served from Terraform Enterprise, keeping a history along
+stored and served from Terraform Enterprise, keeping a history along the way.
-the way.
 
 ## Post-Processors
 
-Packer uses [post-processors](https://packer.io/docs/templates/post-processors.html) to define how to process
+Packer uses
-images and artifacts after provisioning. Both the `vagrant` and `atlas` post-processors must be used in order
+[post-processors](https://packer.io/docs/templates/post-processors.html) to
-to upload Vagrant Boxes to Terraform Enterprise via Packer.
+define how to process images and artifacts after provisioning. Both the
+`vagrant` and `atlas` post-processors must be used in order to upload Vagrant
+Boxes to Terraform Enterprise via Packer.
 
 It's important that they are [sequenced](https://packer.io/docs/templates/post-processors.html)
 in the Packer template so they run in order. This is done by nesting arrays:
 
+```javascript
+{
   "post-processors": [
     [
       {
         "type": "vagrant"
-          ...
+        // ...
       },
       {
         "type": "atlas"
-          ...
+        // ...
       }
     ]
   ]
+}
+```
 
 Sequencing automatically passes the resulting artifact from one
 post-processor to the next – in this case, the `.box` file.
@@ -49,10 +54,12 @@ The [Vagrant post-processor](https://packer.io/docs/post-processors/vagrant.html
 from the build (an `.ovf` file, for example) into a `.box` file before
 passing it to the `atlas` post-processor.
 
-    {
+```json
+{
   "type": "vagrant",
   "keep_input_artifact": false
-    }
+}
+```
 
 The input artifact (i.e and `.ovf` file) does not need to be kept when building Vagrant Boxes,
 as the resulting `.box` will contain it.
@@ -61,15 +68,17 @@ as the resulting `.box` will contain it.
 
 The [post-processor](https://packer.io/docs/post-processors/atlas.html) takes the resulting `.box` file and uploads it adding metadata about the box version.
 
-    {
+```json
+{
   "type": "atlas",
-      "artifact": "%{DEFAULT_USERNAME}/dev-environment",
+  "artifact": "my-username/dev-environment",
   "artifact_type": "vagrant.box",
   "metadata": {
     "provider": "vmware_desktop",
     "version": "0.0.1"
   }
-    }
+}
+```
 
 #### Attributes Required
 
@@ -98,6 +107,8 @@ An example post-processor block for Terraform Enterprise and Vagrant is below. I
 the build runs on both VMware and Virtualbox creating two
 different providers for the same box version (`0.0.1`).
 
+```json
+{
   "post-processors": [
     [
       {
@@ -107,7 +118,7 @@ different providers for the same box version (`0.0.1`).
       {
         "type": "atlas",
         "only": ["vmware-iso"],
-          "artifact": "%{DEFAULT_USERNAME}/dev-environment",
+        "artifact": "my-username/dev-environment",
         "artifact_type": "vagrant.box",
         "metadata": {
           "provider": "vmware_desktop",
@@ -117,7 +128,7 @@ different providers for the same box version (`0.0.1`).
       {
         "type": "atlas",
         "only": ["virtualbox-iso"],
-          "artifact": "%{DEFAULT_USERNAME}/dev-environment",
+        "artifact": "my-username/dev-environment",
         "artifact_type": "vagrant.box",
         "metadata": {
           "provider": "virtualbox",
@@ -126,3 +137,5 @@ different providers for the same box version (`0.0.1`).
       }
     ]
   ]
+}
+```

website/source/docs/enterprise/packer/artifacts/index.html.md

@@ -1,6 +1,6 @@
 ---
 layout: "enterprise"
-page_title: "About Packer and Artifacts"
+page_title: "Packer Artifacts - Terraform Enterprise"
 sidebar_current: "docs-enterprise-packerartifacts"
 description: |-
   Packer creates and uploads artifacts to Terraform Enterprise.
@@ -11,12 +11,12 @@ description: |-
 Packer creates and uploads artifacts to Terraform Enterprise. This is done
 with the [post-processor](https://packer.io/docs/post-processors/atlas.html).
 
-Artifacts can then be used to deploy services or access
+Artifacts can then be used to deploy services or access via Vagrant. Artifacts
-via Vagrant. Artifacts are generic, but can be of varying types.
+are generic, but can be of varying types. These types define different behavior
-These types define different behavior within Terraform Enterprise.
+within Terraform Enterprise.
 
-For uploading artifacts `artifact_type` can be set to any
+For uploading artifacts `artifact_type` can be set to any unique identifier,
-unique identifier, however, the following are recommended for consistency.
+however, the following are recommended for consistency.
 
 - `amazon.image`
 - `azure.image`
@@ -33,8 +33,8 @@ unique identifier, however, the following are recommended for consistency.
 - `vagrant.box`
 
 Packer can create artifacts when running in Terraform Enterprise or locally.
-This is possible due to the post-processors use of the public
+This is possible due to the post-processors use of the public artifact API to
-artifact API to store the artifacts.
+store the artifacts.
 
-You can read more about artifacts and their use in the [Terraform section](/docs/enterprise/)
+You can read more about artifacts and their use in the
-of the documentation.
+[Terraform section](/docs/enterprise/) of the documentation.

website/source/docs/enterprise/packer/builds/build-environment.html.md

@@ -1,6 +1,6 @@
 ---
 layout: "enterprise"
-page_title: "Packer Build Environment"
+page_title: "Build Environment - Packer Builds - Terraform Enterprise"
 sidebar_current: "docs-enterprise-packerbuilds-environment"
 description: |-
   This page outlines the environment that Packer runs in within Terraform Enterprise.
@@ -8,7 +8,8 @@ description: |-
 
 # Packer Build Environment
 
-This page outlines the environment that Packer runs in within Terraform Enterprise.
+This page outlines the environment that Packer runs in within Terraform
+Enterprise.
 
 ### Supported Builders
 
@@ -40,6 +41,8 @@ with [Packer Provisioners](https://packer.io/docs/templates/provisioners.html).
 
 An example of this with the Shell provisioner is below.
 
+```json
+{
   "provisioners": [
     {
       "type": "shell",
@@ -50,6 +53,8 @@ An example of this with the Shell provisioner is below.
       ]
     }
   ]
+}
+```
 
 We encourage use of relative paths over absolute paths to maintain portability
 between Terraform Enterprise and local builds.
@@ -129,9 +134,9 @@ resource was created outside of GitHub (like using `packer push` or
 
 ### Base Artifact Variable Injection
 
-A base artifact can be selected on the "Settings" page for a build configuration.
+A base artifact can be selected on the "Settings" page for a build
-During each build, the latest artifact version will have it's external
+configuration. During each build, the latest artifact version will have it's
-ID (such as an AMI for AWS) injected as an environment variable for the
+external ID (such as an AMI for AWS) injected as an environment variable for the
 environment.
 
 The keys for the following artifact types will be injected:
@@ -144,7 +149,8 @@ The keys for the following artifact types will be injected:
 You can then reference this artifact in your Packer template, like this
 AWS example:
 
-    {
+```json
+{
   "variables": {
       "base_ami": "{{env `ATLAS_BASE_ARTIFACT_AWS_AMI_ID`}}"
   },
@@ -157,9 +163,8 @@ AWS example:
       "source_ami": "{{user `base_ami`}}"
     }
   ]
-    }
+}
-
+```
-- - -
 
 ## Notes on Security
 

website/source/docs/enterprise/packer/builds/how-builds-run.html.md

@@ -1,6 +1,6 @@
 ---
 layout: "enterprise"
-page_title: "Running Packer Builds"
+page_title: "Running - Packer Builds - Terraform Enterprise"
 sidebar_current: "docs-enterprise-packerbuilds-runbuilds"
 description: |-
   This briefly covers the internal process of running builds in Terraform Enterprise.
@@ -8,25 +8,30 @@ description: |-
 
 # How Packer Builds Run in Terraform Enterprise
 
-This briefly covers the internal process of running builds in Terraform Enterprise. It's
+This briefly covers the internal process of running builds in Terraform
-not necessary to know this information, but may be valuable to
+Enterprise. It's not necessary to know this information, but may be valuable to
-help understand implications of running or debugging failing
+help understand implications of running or debugging failing builds.
-builds.
 
 ### Steps of Execution
 
-1. A Packer template and directory of files is uploaded via Packer Push or GitHub
+1. A Packer template and directory of files is uploaded via Packer Push or
-2. Terraform Enterprise creates a version of the build configuration and waits for the upload
+GitHub
-to complete. At this point, the version will be visible in the UI even if the upload has
+
-not completed
+2. Terraform Enterprise creates a version of the build configuration and waits
-3. Once the upload finishes, the build is queued. This is potentially
+for the upload to complete. At this point, the version will be visible in the UI
-split across multiple machines for faster processing
+even if the upload has not completed
+
+3. Once the upload finishes, the build is queued. This is potentially split
+across multiple machines for faster processing
+
 4. In the build environment, the package including the files and Packer template
 are downloaded
-5. `packer build` is run against the template in the build environment
-6. Logs are streamed into the UI and stored
-7. Any artifacts as part of the build are then uploaded via the public
-artifact API, as they would be if Packer was executed locally
-8. The build completes, the environment is teared down and status
-updated
 
+5. `packer build` is run against the template in the build environment
+
+6. Logs are streamed into the UI and stored
+
+7. Any artifacts as part of the build are then uploaded via the public artifact
+API, as they would be if Packer was executed locally
+
+8. The build completes, the environment is teared down and status updated

website/source/docs/enterprise/packer/builds/index.html.md

@@ -1,6 +1,6 @@
 ---
 layout: "enterprise"
-page_title: "About Builds"
+page_title: "Packer Builds - Terraform Enterprise"
 sidebar_current: "docs-enterprise-packerbuilds"
 description: |-
   Builds are instances of `packer build` being run within Terraform Enterprise.
@@ -8,24 +8,28 @@ description: |-
 
 # About Builds
 
-Builds are instances of `packer build` being run within Terraform Enterprise. Every
+Builds are instances of `packer build` being run within Terraform Enterprise.
-build belongs to a build configuration.
+Every build belongs to a build configuration.
 
 __Build configurations__ represent a set of Packer configuration versions and
-builds run. It is used as a namespace within Terraform Enterprise, Packer commands and URLs. Packer
+builds run. It is used as a namespace within Terraform Enterprise, Packer
-configuration sent to Terraform Enterprise are stored and versioned under
+commands and URLs. Packer configuration sent to Terraform Enterprise are stored
-these build configurations.
+and versioned under these build configurations.
 
 These __versions__ of Packer configuration can contain:
 
-- The Packer template, a JSON file which define one or
+- The Packer template, a JSON file which define one or more builds by
-more builds by configuring the various components of Packer
+  configuring the various components of Packer
+
 - Any provisioning scripts or packages used by the template
-- Applications that use the build as part of the pipeline and merged into the version prior to running Packer on it
 
-When a new version of Packer configuration and associated
+- Applications that use the build as part of the pipeline and merged into the
-scripts from GitHub or `packer push` is received, it automatically starts a new
+  version prior to running Packer on it
-Packer build. That Packer build runs in an isolated machine environment with the contents
-of that version available to it.
 
-You can be alerted of build events with [Build Notifications](/docs/enterprise/packer/builds/notifications.html).
+When a new version of Packer configuration and associated scripts from GitHub or
+`packer push` is received, it automatically starts a new Packer build. That
+Packer build runs in an isolated machine environment with the contents of that
+version available to it.
+
+You can be alerted of build events with
+[Build Notifications](/docs/enterprise/packer/builds/notifications.html).

website/source/docs/enterprise/packer/builds/installing-software.html.md

@@ -1,6 +1,6 @@
 ---
 layout: "enterprise"
-page_title: "Installing Software with Packer"
+page_title: "Installing Software - Packer Builds - Terraform Enterprise"
 sidebar_current: "docs-enterprise-packerbuilds-installing"
 description: |-
   Installing software with Packer.

website/source/docs/enterprise/packer/builds/managing-packer-versions.html.md

@@ -1,6 +1,6 @@
 ---
 layout: "enterprise"
-page_title: "Managing Packer Versions"
+page_title: "Managing Packer Versions - Packer Builds - Terraform Enterprise"
 sidebar_current: "docs-enterprise-packerbuilds-versions"
 description: |-
   Terraform Enterprise does not automatically upgrade the version of Packer used to run builds or compiles.
@@ -8,20 +8,21 @@ description: |-
 
 # Managing Packer Versions
 
-Terraform Enterprise does not automatically upgrade the version of Packer
+Terraform Enterprise does not automatically upgrade the version of Packer used
-used to run builds or compiles. This is intentional, as occasionally
+to run builds or compiles. This is intentional, as occasionally there can be
-there can be backwards incompatible changes made to Packer that cause templates to stop
+backwards incompatible changes made to Packer that cause templates to stop
 building properly, or new versions that produce some other unexpected behavior.
 
-All upgrades must be performed by a user, but Terraform Enterprise will display a notice
+All upgrades must be performed by a user, but Terraform Enterprise will display
-above any builds run with out of date versions. We encourage the use
+a notice above any builds run with out of date versions. We encourage the use of
-of the latest version when possible.
+the latest version when possible.
 
 ### Upgrading Packer
 
 1. Go the Settings tab of a build configuration or application
-2. Go to the "Packer Version" section and select the version you
+
-wish to use
+2. Go to the "Packer Version" section and select the version you wish to use
+
 3. Review the changelog for that version and previous versions
-4. Click the save button. At this point, future builds will use that
+
-version
+4. Click the save button. At this point, future builds will use that version

website/source/docs/enterprise/packer/builds/notifications.html.md

@@ -1,6 +1,6 @@
 ---
 layout: "enterprise"
-page_title: "About Packer Build Notifications"
+page_title: "Build Notifications - Packer Builds - Terraform Enterprise"
 sidebar_current: "docs-enterprise-packerbuilds-notifications"
 description: |-
   Terraform Enterprise can send build notifications to your organization.

website/source/docs/enterprise/packer/builds/rebuilding.html.md

@@ -1,6 +1,6 @@
 ---
 layout: "enterprise"
-page_title: "Rebuilding Builds"
+page_title: "Rebuilding - Packer Builds - Terraform Enterprise"
 sidebar_current: "docs-enterprise-packerbuilds-rebuilding"
 description: |-
   Sometimes builds fail due to temporary or remotely controlled conditions.
@@ -10,11 +10,11 @@ description: |-
 
 Sometimes builds fail due to temporary or remotely controlled conditions.
 
-In this case, it may make sense to "rebuild" a Packer build. To do so,
+In this case, it may make sense to "rebuild" a Packer build. To do so, visit the
-visit the build you wish to run again and click the Rebuild button. This
+build you wish to run again and click the Rebuild button. This will take that
-will take that exact version of configuration and run it again.
+exact version of configuration and run it again.
 
-You can rebuild at any point in history, but this may cause side effects
+You can rebuild at any point in history, but this may cause side effects that
-that are not wanted. For example, if you were to rebuild an old version
+are not wanted. For example, if you were to rebuild an old version of a build,
-of a build, it may create the next version of an artifact that is then released,
+it may create the next version of an artifact that is then released, causing a
-causing a rollback of your configuration to occur.
+rollback of your configuration to occur.

website/source/docs/enterprise/packer/builds/scheduling-builds.html.md

@@ -1,6 +1,6 @@
 ---
 layout: "enterprise"
-page_title: "Schedule Periodic Builds"
+page_title: "Schedule Periodic Builds - Packer Builds - Terraform Enterprise"
 sidebar_current: "docs-enterprise-packerbuilds-scheduling"
 description: |-
   Terraform Enterprise can automatically run a Packer build and create artifacts on a specified schedule.
@@ -12,22 +12,23 @@ Terraform Enterprise can automatically run a Packer build and
 create artifacts on a specified schedule. This option is disabled by default and can be enabled by an
 organization owner on a per-[environment](/docs/enterprise/glossary#environment) basis.
 
-On the specified interval, builds will be automatically queued that
+On the specified interval, builds will be automatically queued that run Packer
-run Packer for you, creating any artifacts and sending the appropriate
+for you, creating any artifacts and sending the appropriate notifications.
-notifications.
 
-If your artifacts are used in any other environments and you have activated
+If your artifacts are used in any other environments and you have activated the
-the plan on artifact upload feature, this may also queue Terraform
+plan on artifact upload feature, this may also queue Terraform plans.
-plans.
 
-This feature is useful for maintenance of images and automatic updates,
+This feature is useful for maintenance of images and automatic updates, or to
-or to build nightly style images for staging or development environments.
+build nightly style images for staging or development environments.
 
 ## Enabling Periodic Builds
 
-To enable periodic builds for a build, visit the build settings page and select the desired interval and click the save button to persist the changes. An initial build may immediately run, depending
+To enable periodic builds for a build, visit the build settings page and select
-on the history, and then will automatically build at the specified interval.
+the desired interval and click the save button to persist the changes. An
+initial build may immediately run, depending on the history, and then will
+automatically build at the specified interval.
 
-If you have run a build separately, either manually or triggered from GitHub
+If you have run a build separately, either manually or triggered from GitHub or
-or Packer configuration version uploads, Terraform Enterprise will not queue a new
+Packer configuration version uploads, Terraform Enterprise will not queue a new
-build until the alloted time after the manual build ran. This ensures that a build has been executed at the specified schedule.
+build until the allowed time after the manual build ran. This ensures that a
+build has been executed at the specified schedule.

website/source/docs/enterprise/packer/builds/starting.html.md

@@ -1,6 +1,6 @@
 ---
 layout: "enterprise"
-page_title: "Starting Packer Builds in Terraform Enterprise"
+page_title: "Starting - Packer Builds - Terraform Enterprise"
 sidebar_current: "docs-enterprise-packerbuilds-starting"
 description: |-
   Packer builds can be started in Terraform Enterprise in two ways. This post is about how.
@@ -8,33 +8,36 @@ description: |-
 
 # Starting Packer Builds in Terraform Enterprise
 
-Packer builds can be started in in two ways: `packer push`
+Packer builds can be started in in two ways: `packer push` to upload the
-to upload the template and directory or via a GitHub connection that retrieves
+template and directory or via a GitHub connection that retrieves the contents of
-the contents of a repository after changes to the default branch (usually
+a repository after changes to the default branch (usually master).
-master).
 
 ### Packer Push
 
-Packer `push` is a [Packer command](https://packer.io/docs/command-line/push.html)
+Packer `push` is a
-that packages and uploads a Packer template and directory. This then creates a build which performs `packer build` against the uploaded template
+[Packer command](https://packer.io/docs/command-line/push.html) that packages
-and packaged directory.
+and uploads a Packer template and directory. This then creates a build which
+performs `packer build` against the uploaded template and packaged directory.
 
-The directory is included in order to run any associated provisioners,
+The directory is included in order to run any associated provisioners, builds or
-builds or post-processors that all might use local files. For example,
+post-processors that all might use local files. For example, a shell script or
-a shell script or set of Puppet modules used in a Packer build needs
+set of Puppet modules used in a Packer build needs to be part of the upload for
-to be part of the upload for Packer to be run remotely.
+Packer to be run remotely.
 
 By default, everything in your directory is uploaded as part of the push.
 
-However, it's not always the case that the entire directory should be uploaded. Often,
+However, it's not always the case that the entire directory should be uploaded.
-temporary or cache directories and files like `.git`, `.tmp` will be included by default. This
+Often, temporary or cache directories and files like `.git`, `.tmp` will be
-can cause builds to fail at certain sizes and should be avoided. You can
+included by default. This can cause builds to fail at certain sizes and should
-specify [exclusions](https://packer.io/docs/templates/push.html#exclude) to avoid this situation.
+be avoided. You can specify
+[exclusions](https://packer.io/docs/templates/push.html#exclude) to avoid this
+situation.
 
-Packer also allows for a [VCS option](https://packer.io/docs/templates/push.html#vcs)
+Packer also allows for a
-that will detect your VCS (if there is one) and only upload the files that are tracked by the VCS.
+[VCS option](https://packer.io/docs/templates/push.html#vcs) that will detect
-This is useful for automatically excluding ignored files. In a VCS
+your VCS (if there is one) and only upload the files that are tracked by the
-like git, this basically does a `git ls-files`.
+VCS. This is useful for automatically excluding ignored files. In a VCS like
+git, this basically does a `git ls-files`.
 
 
 ### GitHub Webhooks

website/source/docs/enterprise/packer/builds/troubleshooting.html.md

@@ -1,6 +1,6 @@
 ---
 layout: "enterprise"
-page_title: "Troubleshooting Failing Builds"
+page_title: "Troubleshooting - Packer Builds - Terraform Enterprise"
 sidebar_current: "docs-enterprise-packerbuilds-troubleshooting"
 description: |-
   Packer builds can fail in Terraform Enterprise for a number of reasons – improper configuration, transient networking errors, and hardware constraints are all possible.
@@ -8,8 +8,8 @@ description: |-
 
 # Troubleshooting Failing Builds
 
-Packer builds can fail in Terraform Enterprise for a number of reasons – improper
+Packer builds can fail in Terraform Enterprise for a number of reasons –
-configuration, transient networking errors, and hardware constraints
+improper configuration, transient networking errors, and hardware constraints
 are all possible. Below is a list of debugging options you can use.
 
 ### Verbose Packer Logging
@@ -20,24 +20,27 @@ in Packer. Set the `PACKER_LOG` key to a value of `1` to accomplish this.
 After setting the variable, you'll need to [rebuild](/docs/enterprise/packer/builds/rebuilding.html).
 
 Verbose logging will be much louder than normal Packer logs and isn't
-recommended for day-to-day operations. Once enabled, you'll be able to
+recommended for day-to-day operations. Once enabled, you'll be able to see in
-see in further detail why things failed or what operations Packer was performing.
+further detail why things failed or what operations Packer was performing.
 
 This can also be used locally:
 
-    PACKER_LOG=1 packer build ...
+```text
+$ PACKER_LOG=1 packer build ...
+```
 
 ### Hanging Builds
 
-Some VM builds, such as VMware or Virtualbox, may hang at various stages,
+Some VM builds, such as VMware or VirtualBox, may hang at various stages,
 most notably `Waiting for SSH...`.
 
 Things to pay attention to when this happens:
 
-- SSH credentials must be properly configured. AWS keypairs should
+- SSH credentials must be properly configured. AWS keypairs should match, SSH
-match, SSH usernames should be correct, passwords should match, etc.
+  usernames should be correct, passwords should match, etc.
-- Any VM pre-seed configuration should have the same SSH configuration
+
-as your template defines
+- Any VM pre-seed configuration should have the same SSH configuration as your
+  template defines
 
 A good way to debug this is to manually attempt to use the same SSH
 configuration locally, running with `packer build -debug`. See
@@ -52,8 +55,8 @@ _Typically_ Packer builds that fail due to requesting hardware limits
 that exceed Terraform Enterprise's [hardware limitations](/docs/enterprise/packer/builds/build-environment.html#hardware-limitations)
 will fail with a _The operation was canceled_ error message as shown below:
 
-```
+```text
-...
+# ...
 ==> vmware-iso: Starting virtual machine...
     vmware-iso: The VM will be run headless, without a GUI. If you want to
     vmware-iso: view the screen of the VM, connect via VNC without a password to
@@ -72,13 +75,13 @@ Build 'vmware-iso' errored: Error starting VM: VMware error: Error: The operatio
 Sometimes it's faster to debug failing builds locally. In this case,
 you'll want to [install Packer](https://www.packer.io/intro/getting-started/setup.html) and any providers (like Virtualbox) necessary.
 
-Because Terraform Enterprise runs the open source version of Packer, there should be
+Because Terraform Enterprise runs the open source version of Packer, there
-no difference in execution between the two, other than the environment that
+should be no difference in execution between the two, other than the environment
-Packer is running in. For more on hardware constraints in the Terraform Enterprise environment
+that Packer is running in. For more on hardware constraints in the Terraform
-read below.
+Enterprise environment read below.
 
-Once your builds are running smoothly locally you can push it up to Terraform Enterprise
+Once your builds are running smoothly locally you can push it up to Terraform
-for versioning and automated builds.
+Enterprise for versioning and automated builds.
 
 ### Internal Errors
 
@@ -89,11 +92,12 @@ to properly unpack. This can be caused by bad permissions, using
 symlinks or very large repository sizes. Using symlinks inside of the
 packer directory, or the root of the repository, if the packer directory
 is unspecified, will result in this internal error.
-_**Note:** Most often this error occurs
+
-when applications or builds are linked to a GitHub repository and the 
+    _**Note:** Most often this error occurs when applications or builds are
-directory and/or template paths are incorrect. Double check that the paths 
+    linked to a GitHub repository and the directory and/or template paths are
-specified when you linked the GitHub repository match the actual paths 
+    incorrect. Double check that the paths specified when you linked the GitHub
-to your template file._
+    repository match the actual paths to your template file._
+
 - SEC-001: Your data was being unpacked from a tarball uploaded
 and encountered an error. This can be caused by bad permissions, using
 symlinks or very large tarball sizes.
@@ -111,6 +115,6 @@ the mailing list or IRC. All bug reports should go to GitHub.
 
 ### Getting Support
 
-If you believe your build is failing as a result of a bug in Terraform Enterprise,
+If you believe your build is failing as a result of a bug in Terraform
-or would like other support, please [email us](mailto:support@hashicorp.com).
+Enterprise, or would like other support, please
-
+[email us](mailto:support@hashicorp.com).