TFE Docs text/spelling changes

website/source/docs/enterprise/artifacts/artifact-provider.html.md

@@ -1,9 +1,9 @@
 ---
 layout: "artifacts"
 page_title: "Artifact Provider"
-sidebar_current: "docs-enterprise-Provider"
+sidebar_current: "docs-enterprise-artifact-provider"
 description: |-
-  Terraform has a provider for managing Atlas artifacts called `atlas_artifact`.
+  Terraform has a provider for managing artifacts called `atlas_artifact`.
 ---
 
 # Artifact Provider

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

@@ -1,7 +1,7 @@
 ---
 layout: "artifacts"
 page_title: "Creating AMI Artifacts"
-sidebar_current: "docs-enterprise-amis"
+sidebar_current: "docs-enterprise-artifact-amis"
 description: |-
   Creating AMI Artifacts with Packer.
 ---

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

@@ -6,7 +6,7 @@ description: |-
   Terraform Enterprise can be used to store artifacts for use by Terraform. Typically, artifacts are stored with Packer.
 ---
 
-# About Terraform Artifacts in Atlas
+# About Terraform Artifacts
 
 Terraform Enterprise can be used to store artifacts for use by Terraform. Typically,
 artifacts are [stored with Packer](https://packer.io/docs).

website/source/docs/enterprise/artifacts/managing-versions.html.md

@@ -1,7 +1,7 @@
 ---
 layout: "artifacts"
 page_title: "Managing Artifact Versions"
-sidebar_current: "docs-enterprise-Provider"
+sidebar_current: "docs-enterprise-artifact-versions"
 description: |-
   Artifacts are versioned and assigned a version number, here is how to manage the versions.
 ---
@@ -12,7 +12,7 @@ Artifacts stored in Terraform Enterprise are versioned and assigned a version nu
 Versions are useful to roll back, audit and deploy images specific versions
 of images to certain environments in a targeted way.
 
-This assumes you are familiar with the [Atlas artifact provider](https://terraform.io/docs/providers/atlas/index.html)
+This assumes you are familiar with the [artifact provider](https://terraform.io/docs/providers/atlas/index.html)
 in Terraform.
 
 ### Finding the Version of an Artifact

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

@@ -8,7 +8,7 @@ description: |-
 
 # Terraform Enterprise Features
 
-[Terraform](https://www.hashicorp.com/products/terraform/) is a tool for safely and
+[Terraform Enterprise](https://www.hashicorp.com/products/terraform/) is a tool for safely and
 efficiently changing infrastructure across providers.
 
 This is a list of features specific to Terraform Enterprise.

website/source/docs/enterprise/runs/automatic-applies.html.md

@@ -14,7 +14,7 @@ description: |-
   </div>
 </div>
 
-Atlas can optionally automatically apply successful Terraform plans to your
+You can automatically apply successful Terraform plans to your
 infrastructure. This option is disabled by default and can be enabled by an
 organization owner on a per-environment basis.
 
@@ -28,7 +28,6 @@ organization owner on a per-environment basis.
 
 ## Enabling Auto-Apply
 
-To enable auto-apply for an environment, visit the environment settings page in
+To enable auto-apply for an environment, visit the environment settings page check the box labeled "auto apply" and click the save button to
-Atlas and check the box labeled "auto apply" and click the save button to
 persist the changes. The next successful Terraform plan for the environment will
 automatically apply without user confirmation.

website/source/docs/enterprise/runs/how-runs-execute.html.md

@@ -16,7 +16,7 @@ runs.
 ## Steps of Execution
 
 1. A set of Terraform configuration and directory of files is uploaded via Terraform Push or GitHub
-2. Atlas creates a version of the Terraform configuration and waits for the upload
+2. Terraform Enterprise creates a version of the Terraform configuration and waits for the upload
 to complete. At this point, the version will be visible in the UI even if the upload has
 not completed
 3. Once the upload finishes, Terraform Enterprise creates a run and queues a `terraform plan`
@@ -48,12 +48,11 @@ These are:
 - The directory that contains your environment's Terraform configuration can be customized 
 to support directory structures with more than one set of Terraform configuration files.
 To customize the directory for your Environment, set the _Terraform Directory_ 
-property in the _GitHub Integration_ settings for your environment. This is equivalent to 
+property in the [_GitHub Integration_](/docs/enterprise/vcs/github.html) settings for your environment. This is equivalent to 
 passing the `[dir]` argument when running Terraform in your local shell.
 - The directory in which Terraform is executed from can be customized to support directory 
 structures with nested sub-directories or configurations that use Terraform modules with 
-relative paths. To customize the directory used for Terraform execution in your  
+relative paths. To customize the directory used for Terraform execution in your Environment, set the `TF_ATLAS_DIR` 
-Environment, set the `TF_ATLAS_DIR` 
+[environment variable](/docs/enterprise/runs/variables-and-configuration.html#environment-variables)
-[environment variable](/docs/enterprise/runs/variables-and-configuration#environment-variables)
 to the relative path of the directory - ie. `terraform/production`. This is equivalent to 
 changing directories to the appropriate path in your local shell and then executing Terraform.

website/source/docs/enterprise/runs/index.html.md

@@ -26,7 +26,7 @@ Terraform plans and applies below.
 During the plan phase of a run, the command `terraform plan` is executed.
 Terraform performs a refresh and then determines what actions are necessary to
 reach the desired state specified in the Terraform configuration files. A
-successful plan outputs an executable file that is securely stored in Atlas
+successful plan outputs an executable file that is securely stored in Terrafrom Enterprise
 and may be used in the subsequent apply.
 
 Terraform plans do not change the state of infrastructure, so it is
@@ -45,9 +45,9 @@ While Terraform plans are safe to run multiple times, Terraform applies often
 change active infrastructure. Because of this, the default behavior 
 is to require user confirmation as part of the
 [Terraform run execution](/docs/enterprise/runs/how-runs-execute.html). Upon
-user confirmation, Atlas will queue and execute the Terraform apply. It is also
+user confirmation, the Terraform apply will be queued and executed. It is also
-possible to configure Atlas to
+possible to configure 
-[automatically apply](/docs/enterprise/runs/automatic-applies.html), but this option is
+[automatic applies](/docs/enterprise/runs/automatic-applies.html), but this option is
 disabled by default.
 
 ## Environment Locking

website/source/docs/enterprise/runs/scheduling-runs.html.md

@@ -37,6 +37,6 @@ persist the changes. An initial plan may immediately run, depending
 on the state of your environment, and then will automatically
 plan at the specified interval.
 
-If you have manually run a plan separately, Atlas will not queue a new
+If you have manually run a plan separately, a new
-plan until the alloted time after the manual plan ran. This means that
+plan will not be queued until the allotted time after the manual plan ran. This means that
-Atlas simply ensures that a plan has been executed at the specified schedule.
+the platform simply ensures that a plan has been executed at the specified schedule.

website/source/docs/enterprise/runs/starting.html.md

@@ -7,13 +7,13 @@ description: |-
 ---
 
 
-# Starting Terraform Runs in Atlas
+# Starting Terraform Runs
 
-There are a variety of ways to queue a Terraform run in Atlas. In addition to
+There are a variety of ways to queue a Terraform run in Terraform Enterprise. In addition to
-`terraform push`, you can connect your [environment](/help/glossary#environment)
+`terraform push`, you can connect your environment
-to GitHub and have Atlas queue Terraform runs based on new commits. Atlas can
+to GitHub and runs based on new commits. You can
 also intelligently queue new runs when linked artifacts are uploaded or changed.
-Remember from the [previous section about Terraform runs](/help/terraform/runs)
+Remember from the [previous section about Terraform runs](/docs/enterprise/runs)
 that it is safe to trigger many plans without consequence since Terraform plans
 do not change infrastructure.
 
@@ -21,8 +21,8 @@ do not change infrastructure.
 ## Terraform Push
 
 Terraform `push` is a [Terraform command](https://terraform.io/docs/commands/push.html)
-that packages and uploads a set of Terraform configuration and directory to Atlas. This then creates a run
+that packages and uploads a set of Terraform configuration and directory to the platform. This then creates a run
-in Atlas, which performs `terraform plan` and `terraform apply` against the uploaded
+which performs `terraform plan` and `terraform apply` against the uploaded
 configuration.
 
 The directory is included in order to run any associated provisioners,
@@ -32,8 +32,8 @@ that executes a shell script.
 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,
-temporary or cache directories and files like `.git`, `.tmp` will be included by default. This
+temporary or cache directories and files like `.git`, `.tmp` will be included by default, which
-can cause Atlas to fail at certain sizes and should be avoided. You can
+can cause failures at certain sizes and should be avoided. You can
 specify [exclusions](https://terraform.io/docs/commands/push.html) to avoid this situation.
 
 Terraform also allows for a [VCS option](https://terraform.io/docs/commands/push.html#_vcs_true)
@@ -46,14 +46,14 @@ basically does a `git ls-files`.
 
 Optionally, GitHub can be used to import Terraform configuration. When used
 within an organization, this can be extremely valuable for keeping differences
-in environments and last mile changes from occurring before an upload to Atlas.
+in environments and last mile changes from occurring before an upload.
 
-After you have [connected your GitHub account to Atlas](/settings/connections),
+After you have [connected your GitHub account to Terraform Enterprise](/docs/enterprise/vcs/github.html),
-you can connect your [environment](/help/glossary#environment) to the target
+you can connect your environment to the target
-GitHub repository. The GitHub repository will be linked to the Atlas Terraform
+GitHub repository. The GitHub repository will be linked to the Terraform Enterprise
-configuration, and GitHub will start sending webhooks to Atlas. Certain
+configuration, and GitHub will start sending webhooks. Certain
 GitHub webhook events, detailed below, will cause the repository to be
-automatically ingressed into Atlas and stored, along with references to the
+automatically ingressed into Terraform and stored, along with references to the
 GitHub commits and authorship information.
 
 Currently, an environment must already exist to be connected to GitHub. You can
@@ -75,7 +75,7 @@ Supported GitHub webhook events:
   - ingress when a tag is created
   - ingress when the default branch is updated
     - note: the default branch is either configured on your configuration's
-      integrations tab in Atlas, or if that is blank it is the GitHub
+      integrations tab, or if that is blank it is the GitHub
       repository's default branch
 - create (off by default)
   - ingress when a tag is created
@@ -84,35 +84,32 @@ Supported GitHub webhook events:
 
 ## Artifact Uploads
 
-Upon successful completion of a Terraform run, Atlas parses the remote state and
+Upon successful completion of a Terraform run,the remote state is parsed and
-detects any [Atlas artifacts](/help/terraform/artifacts/artifact-provider) that
+any [artifacts](/docs/enterprise/artifacts/artifact-provider.html) are detected that
-were referenced. When new versions of those referenced artifacts are uploaded
+were referenced. When new versions of those referenced artifacts are uploaded, you have the option to automatically queue a new Terraform run.
-to Atlas, you have the option to automatically queue a new Terraform run.
 
 For example, consider the following Terraform configuration which references an
-Atlas artifact named "worker":
+artifact named "worker":
 
     resource "aws_instance" "worker" {
       ami = "${atlas_artifact.worker.metadata_full.region-us-east-1}"
       instance_type = "m1.small"
     }
 
-When a new version of the Atlas artifact "worker" is uploaded either manually
+When a new version of the and artifact "worker" is uploaded either manually
-or as the output of a [Packer build](/help/packer/builds/starting.html), Atlas
+or as the output of a [Packer build](https://atlas.hashicorp.com/help/packer/builds/starting), a Terraform plan can be automatically triggered with this new artifact version.
-can automatically trigger a Terraform plan with this new artifact version.
 You can enable this feature on a per-environment basis from the
-[environment](/help/glossary#environment) settings page in Atlas.
+environment settings page.
 
 Combined with
-[Terraform auto apply](/help/terraform/runs/automatic-applies), you can
+[Terraform auto apply](/docs/enterprise/runs/automatic-applies.html), you can
-continuously deliver infrastructure using Terraform and Atlas.
+continuously deliver infrastructure using Terraform and Terraform Enterprise.
 
 ## Terraform Plugins
 
 If you are using a custom [Terraform Plugin](https://www.terraform.io/docs/plugins/index.html)
 binary for a provider or provisioner that's not currently in a released
-version of Terraform, you can still use this in Atlas.
+version of Terraform, you can still use this in Terraform Enterprise.
 
 All you need to do is include a Linux AMD64 binary for the plugin in the
-directory in which Terraform commands are run from; Atlas will then use
+directory in which Terraform commands are run from; it will then be used next time you `terraform push` or ingress from GitHub.
-the plugin the next time you `terraform push` or ingress from GitHub.

website/source/docs/enterprise/runs/variables-and-configuration.html.md

@@ -1,7 +1,7 @@
 ---
 layout: "runs"
 page_title: "Runs: Variables and Configuration"
-sidebar_current: "docs-enterprise-runs-schedule"
+sidebar_current: "docs-enterprise-runs-variables"
 description: |-
   How to configure runs and their variables.
 ---
@@ -18,7 +18,7 @@ define the parameterization of Terraform configurations and are important
 for sharing and removal of sensitive secrets from version control.
 
 Variables are sent with the `terraform push` command. Any variables in your local
-`.tfvars` files are securely uploaded. Once variables are uploaded, Terraform will prefer the Atlas-stored variables over any changes you
+`.tfvars` files are securely uploaded. Once variables are uploaded, Terraform will prefer the stored variables over any changes you
 make locally. Please refer to the
 [Terraform push documentation](https://www.terraform.io/docs/commands/push.html)
 for more information.
@@ -92,7 +92,7 @@ Set the [variables](https://www.terraform.io/docs/configuration/variables.html)
       }
     }
 
-`terraform push` any "Terraform Variables" to Atlas:
+`terraform push` any "Terraform Variables":
 
     $ terraform push -name $ATLAS_USERNAME/example -var "private_key=$MY_PRIVATE_KEY"
 

website/source/docs/enterprise/state/collaborating.html.md

@@ -8,7 +8,7 @@ description: |-
 
 # Collaborating on Terraform Remote State
 
-Atlas is one of a few options to store [remote state](/docs/enterprise/state).
+Terraform Enterprise is one of a few options to store [remote state](/docs/enterprise/state).
 
 Remote state gives you the ability to version and collaborate on Terraform changes. It
 stores information about the changes Terraform makes based on configuration.

website/source/docs/enterprise/state/index.html.md

@@ -14,11 +14,11 @@ named `terraform.tfstate`, but it can also be stored remotely, which
 works better in a team environment.
 
 Terraform Enterprise is a remote state provider, allowing you to store, version and
-collaborate on state with Atlas.
+collaborate on states.
 
 Remote state gives you more than just easier version control and safer
 storage. It also allows you to delegate the outputs to other teams.
 This allows your infrastructure to be more easily broken down into
 components that multiple teams can access.
 
-Read [more about remote state](https://www.terraform.io/docs/state/remote/index.html).
+Read [more about remote state](https://www.terraform.io/docs/state/remote.html).

website/source/docs/enterprise/vcs/git.html.md

@@ -1,7 +1,7 @@
 ---
 layout: "vcs"
 page_title: "Git Integration"
-sidebar_current: "docs-enterprise-vcs"
+sidebar_current: "docs-enterprise-vcs-git"
 description: |-
   Git repositories can be integrated with Terraform Enterprise by using push command.
 ---
@@ -14,7 +14,7 @@ Terraform configuration when changes are committed. When Terraform
 configuration is imported using `terraform push` a plan is automatically queued.
 
 _**Note:** This integration is for Git repositories **not** hosted on GitHub. 
-For repositories on GitHub, there is native [GitHub Integration](/help/terraform/vcs/github).
+For repositories on GitHub, there is native [GitHub Integration](/docs/enterprise/vcs/github.html).
 
 ## Setup
 
@@ -42,7 +42,7 @@ repository, set the necessary variables, and ensure the script is executable.
 # An example hook script to push Terraform configuration to Terraform Enterprise.
 #
 # Set the following variables for your project:
-# - ENV_NAME - your Atlas environment name (e.g. org/env)
+# - ENV_NAME - your environment name (e.g. org/env)
 # - TERRAFORM_DIR - the local directory to push
 # - DEFAULT_BRANCH - the branch to push. Other branches will be ignored.
 
@@ -58,10 +58,10 @@ fi
 current_branch=$(git symbolic-ref HEAD | sed -e 's,.*/\(.*\),\1,')
 
 if [ "$current_branch" == "$DEFAULT_BRANCH" ]; then
-  echo "pre-push hook: Pushing branch [$current_branch] to Atlas environment [$ENV_NAME]."
+  echo "pre-push hook: Pushing branch [$current_branch] to environment [$ENV_NAME]."
   terraform push -name="$ENV_NAME" $TERRAFORM_DIR
 else
-  echo "pre-push hook: NOT pushing branch [$current_branch] to Atlas environment [$ENV_NAME]."
+  echo "pre-push hook: NOT pushing branch [$current_branch] to environment [$ENV_NAME]."
 fi
 
 ```

website/source/docs/enterprise/vcs/github.html.md

@@ -1,7 +1,7 @@
 ---
 layout: "vcs"
 page_title: "GitHub Integration"
-sidebar_current: "docs-enterprise-vcs"
+sidebar_current: "docs-enterprise-vcs-github"
 description: |-
   GitHub repositories can be integrated with Terraform Enterprise by using push command.
 ---

website/source/docs/enterprise/vcs/index.html.md

@@ -15,5 +15,5 @@ source control.
 Different capabilities within Terraform Enterprise are available depending on the integration
 in use. The available integration options are below.
 
-- [Git](/docs/enterprise/vcs/git)
+- [Git](/docs/enterprise/vcs/git.html)
-- [GitHub](/docs/enterprise/vcs/github)
+- [GitHub](/docs/enterprise/vcs/github.html)

website/source/layouts/artifacts.erb

@@ -7,7 +7,7 @@
 				</li>
 
 				<li<%= sidebar_current(/^docs-enterprise-artifact-/) %>>
-					<a href="/docs/enterprise/artifact/index.html">Artifact</a>
+					<a href="/docs/enterprise/artifacts/index.html">Artifact</a>
 					<ul class="nav nav-visible">
 						<li<%= sidebar_current("docs-enterprise-artifact-provider") %>>
 							<a href="/docs/enterprise/artifacts/artifact-provider.html">Artifact Provider</a>
@@ -15,7 +15,7 @@
 						<li<%= sidebar_current("docs-enterprise-artifact-versions") %>>
 							<a href="/docs/enterprise/artifacts/managing-versions.html">Managing Versions</a>
 						</li>
-						<li<%= sidebar_current("docs-enterprise-artifact-ami") %>>
+						<li<%= sidebar_current("docs-enterprise-artifact-amis") %>>
 							<a href="/docs/enterprise/artifacts/creating-amis.html">Creating AMI Artifacts</a>
 						</li>
 					</ul>

website/source/layouts/runs.erb

@@ -15,7 +15,7 @@
 						<li<%= sidebar_current("docs-enterprise-runs-applies") %>>
 							<a href="/docs/enterprise/runs/automatic-applies.html">Automatic Applies</a>
 						</li>
-						<li<%= sidebar_current("docs-enterprise-runs-scheduling") %>>
+						<li<%= sidebar_current("docs-enterprise-runs-schedule") %>>
 							<a href="/docs/enterprise/runs/scheduling-runs.html">Scheduling Runs</a>
 						</li>
 						<li<%= sidebar_current("docs-enterprise-runs-variables") %>>