Fix a bunch of typos

ZachGoldberg · ZachGoldberg · commit b4334c75620c · 2024-11-20T16:22:45.000-08:00
diff --git a/docs/2.0/docs/accountfactory/guides/collaborators.md b/docs/2.0/docs/accountfactory/guides/collaborators.md
@@ -34,7 +34,7 @@ The options are `pull`, `triage`, `push`, `maintain`, `admin`, or a custom repos
 
 To add a team to new delegated repositories add a new item to the collaborators block in your account factory configuration.
 
-All collaborators in each account type will be added to new repositories of that type when the repository is createde. If you want to add a team to vended repositories of different types you will need to add them in multiple places.
+All collaborators in each account type will be added to new repositories of that type when the repository is created. If you want to add a team to vended repositories of different types you will need to add them in multiple places.
 
 A common scenario is to create a team for administration that is granted access everywhere, and individual teams for each delegated repository.
 
diff --git a/docs/2.0/docs/accountfactory/guides/delegated-repositories.md b/docs/2.0/docs/accountfactory/guides/delegated-repositories.md
@@ -19,12 +19,12 @@ The following options are particularly relevant for delegated repositories and y
 
 #### Catalog Repositories
 
-Catalog Repositories are what your developer teams will use when running `terragrunt catalog` within their delegated repository. This defaults to your `infrastructure-modules` reposistory but you can customize this list and the values will be vended into the newly createed repository.
+Catalog Repositories are what your developer teams will use when running `terragrunt catalog` within their delegated repository. This defaults to your `infrastructure-modules` repository but you can customize this list and the values will be vended into the newly created repository.
 
 [catalog-repositories](/2.0/reference/accountfactory/configurations#catalog-repositories)
 
 
-#### GitHub Collaboratoes
+#### GitHub Collaborators
 
 GitHub Collaborators is a list of teams to automatically grant access to the new repository. This is optional to use as you can also manually set up access controls, but we do recommend configuring some teams and permissions to smooth out the vending process.
 
@@ -128,7 +128,7 @@ To summarize, at this point you will have:
 - Provisioned a new AWS account(s)
 - Applied baselines for the new account(s)
 - Created a new repository to manage infrastructure changes in this account(s)
-- Configured new IAM roles to manage permissions in the delgated repository
+- Configured new IAM roles to manage permissions in the delegated repository
 - Bootstrapped the repository ready to add new infrastructure
 
 You can now start adding new infrastructure to the delegated repository.
diff --git a/docs/2.0/docs/accountfactory/guides/iam-roles.md b/docs/2.0/docs/accountfactory/guides/iam-roles.md
@@ -64,6 +64,6 @@ See the full description of the `iam_policy` input [in the library reference](/r
 
 To add IAM roles to all delegated repositories you can modify the base roles in `_envcommon/landingzone/delegated-pipelines-plan-role.hcl` and `_envcommon/landingzone/delegated-pipelines-apply-role.hcl`.
 
-These HCL files also contain a `iam_policy` block which is already populated with the necesary policies for terragrunt to store state and perform barebones plans and applies.
+These HCL files also contain a `iam_policy` block which is already populated with the necessary policies for terragrunt to store state and perform bare-bones plans and applies.
 
 You can expand this block by adding new policy descriptions, and they will be granted to all delegated repositories.
diff --git a/docs/2.0/docs/accountfactory/guides/vend-aws-account.md b/docs/2.0/docs/accountfactory/guides/vend-aws-account.md
@@ -4,7 +4,7 @@
 
 The Account Factory Workflow in your `infrastructure-live-root` repository can be used to vend new AWS accounts. It takes a single input consisting of a JSON payload that you can generate from the `account-factory-inputs.html` web page.
 
-We use a JSON payload to support more vending opitions, as GitHub Workflows are limited to only 10 inputs.
+We use a JSON payload to support more vending options, as GitHub Workflows are limited to only 10 inputs.
 
 :::note
 This guide pertains only to non-delegated repositories. Enterprise customers are also able to [use Account Factory to create new Delegated Repositories](/2.0/docs/accountfactory/guides/delegated-repositories).
diff --git a/docs/2.0/docs/library/architecture/opentofu-terraform-compatibility.md b/docs/2.0/docs/library/architecture/opentofu-terraform-compatibility.md
@@ -15,7 +15,7 @@ This is the last version of HashiCorp Terraform that is licensed under the MPLv2
 
 ## What if I want to use a version of Terraform above v1.5.7?
 
-Going forward, we recommend that all Gruntwork customers adopt [OpenTofu](https://opentofu.org/) as a "drop-in" replacement for HashiCorp Terraform. We will be developing against OpenTofu releases, testing for compatiability with OpenTofu, and offering full support for any issues you experience with our modules and OpenTofu.
+Going forward, we recommend that all Gruntwork customers adopt [OpenTofu](https://opentofu.org/) as a "drop-in" replacement for HashiCorp Terraform. We will be developing against OpenTofu releases, testing for compatibility with OpenTofu, and offering full support for any issues you experience with our modules and OpenTofu.
 
 ## As a user of Gruntwork Library, do I need to change anything?
 
diff --git a/docs/2.0/docs/library/concepts/principles/control-provider-usage.md b/docs/2.0/docs/library/concepts/principles/control-provider-usage.md
@@ -9,7 +9,7 @@ There are two main methods for controlling the provider used in OpenTofu/Terrafo
 
 Generally speaking, follow [OpenTofu recommendations](https://opentofu.org/docs/language/providers/requirements/#best-practices-for-provider-versions) regarding specifying the minimum provider version for any providers used by modules authored as part of the library.
 
-This recommendation is useful guidance for ensuring that the feature set used as part of modules being authored for the library are available in provider verisons end users install.
+This recommendation is useful guidance for ensuring that the feature set used as part of modules being authored for the library are available in provider versions end users install.
 
 You can do that by using a `required_provider` configuration block like the following:
 
@@ -30,7 +30,7 @@ Because only one version of a provider is ultimately installed by end users, con
 
 An exception to the general rule of avoiding pinning maximum provider versions in modules is to prevent a module from pulling in breaking changes from a future version of a provider.
 
-## Comitting `.terraform.lock.hcl` File
+## Committing `.terraform.lock.hcl` File
 
 When running `tofu init` in a directory with `.tf` files, a [`.terraform.lock.hcl`](https://opentofu.org/docs/language/files/dependency-lock) file will be automatically generated if it doesn't exist.
 
@@ -39,4 +39,3 @@ This file shouldn't be committed in module repositories, but should be committed
 When using Terragrunt, note how [Terragrunt handles lock files](https://terragrunt.gruntwork.io/docs/features/lock-file-handling/).
 
 Keep this behavior in mind when deciding how to handle `.terraform.lock.hcl` files in modules.
-
diff --git a/docs/2.0/docs/library/guides/contributing.md b/docs/2.0/docs/library/guides/contributing.md
@@ -54,7 +54,7 @@ to include the following:
 As a Gruntwork customer you will have *read* access to Gruntwork repositories.  This means you will not be able to push a branch directly
 to our repositories.  Instead, to open a pull request you should:
 
-* Fork our repositories into a repository in an organiztion you have write access to
+* Fork our repositories into a repository in an organization you have write access to
 * Push a branch to your repository
 * Open a PR in our repository with the base as our main/master branch, and the "compare" branch being the branch in your repository.
 
diff --git a/docs/2.0/docs/overview/concepts/iac-platform.md b/docs/2.0/docs/overview/concepts/iac-platform.md
@@ -4,4 +4,4 @@ Gruntwork's platform is built for teams adopting OpenTofu and Terragrunt. Our pr
 
 ## Do I have to use Terragrunt?
 
-Several Gruntwork platform products, such as [Pipelines](/2.0/docs/pipelines/concepts/overview) and [Account Factory](/2.0/docs/accountfactory/concepts/) are built explicitly ontop of features of Terragrunt and thus require that organizations adopt Terragrunt as part of their IaC platform. Other products, such as the [Library](/2.0/docs/library/concepts/overview) can be used with or without Terragrunt.  We generally do advise Library customers to adopt Terragrunt, we have built Terragrunt specifically to solve problems related to orchestrating OpenTofu at scale and we can best help you achieve a successful implementation if you are using Terragrunt.
+Several Gruntwork platform products, such as [Pipelines](/2.0/docs/pipelines/concepts/overview) and [Account Factory](/2.0/docs/accountfactory/concepts/) are built explicitly on top of features of Terragrunt and thus require that organizations adopt Terragrunt as part of their IaC platform. Other products, such as the [Library](/2.0/docs/library/concepts/overview) can be used with or without Terragrunt.  We generally do advise Library customers to adopt Terragrunt, we have built Terragrunt specifically to solve problems related to orchestrating OpenTofu at scale and we can best help you achieve a successful implementation if you are using Terragrunt.
diff --git a/docs/2.0/docs/patcher/concepts/grouping.md b/docs/2.0/docs/patcher/concepts/grouping.md
@@ -46,7 +46,7 @@ When generating pull requests in CI, the workflow generally involves first invok
 
 ### Patcher Report
 
-Patcher [report](/2.0/reference/patcher/#report) accepts a `--include-dirs` argument. When passed, this will cause `patcher report` to only output updates matching the glob pattern specified. This allows the developer to in essence limit the resulting PR to only a single environment. By invoking `patcher report` multiple times with different `--include-dirs` arguments, the developer can in effect create different PR worklfows for each environment.
+Patcher [report](/2.0/reference/patcher/#report) accepts a `--include-dirs` argument. When passed, this will cause `patcher report` to only output updates matching the glob pattern specified. This allows the developer to in essence limit the resulting PR to only a single environment. By invoking `patcher report` multiple times with different `--include-dirs` arguments, the developer can in effect create different PR workflows for each environment.
 
 Patcher `report` outputs in JSON which can be inspected or iterated over to achieve desired behaviors.
 
diff --git a/docs/2.0/docs/patcher/guides/report.md b/docs/2.0/docs/patcher/guides/report.md
@@ -8,7 +8,7 @@ Example usage:
 patcher report prod
 ```
 
-The report command outpust a list of module dependencies in JSON format to `stdout`, for example:
+The report command outputs a list of module dependencies in JSON format to `stdout`, for example:
 ```json
 [
    "gruntwork-io/terraform-aws-monitoring/logs/load-balancer-access-logs",
diff --git a/docs/2.0/docs/patcher/guides/update.md b/docs/2.0/docs/patcher/guides/update.md
@@ -25,7 +25,7 @@ After scanning for dependencies, Patcher will show you the 'Modules View'.
 
 If all the dependencies are fully up to date, then Patcher shows a tick in the "Up to date" column.
 
-![Patcher update screenshot showing dependendency that is fully up to date](/img/guides/stay-up-to-date/patcher/patcher-update-overview-futd.png)
+![Patcher update screenshot showing dependency that is fully up to date](/img/guides/stay-up-to-date/patcher/patcher-update-overview-futd.png)
 
 If Patcher can update one or more usages of a module to a newer version, then Patcher offers two options:
 
@@ -35,7 +35,7 @@ If Patcher can update one or more usages of a module to a newer version, then Pa
 
 ![Patcher update screenshot showing dependency that can be updated](/img/guides/stay-up-to-date/patcher/patcher-update-overview-update-available.png)
 
-Pressing `ENTER` will update all the usages of that module to either the highest version before the next closest breaking change or the latest version of the dependecy, whichever is encountered first.
+Pressing `ENTER` will update all the usages of that module to either the highest version before the next closest breaking change or the latest version of the dependency, whichever is encountered first.
 
 Pressing `b` will update all the usages of that module to either the next closest breaking change or the latest version of the dependency, whichever is encountered first.
 
@@ -92,7 +92,7 @@ patcher update --non-interactive --skip-container-runtime prod
 
 Using the [next breaking update strategy](/2.0/docs/patcher/concepts/update-strategies#next-breaking-update-strategy), if Patcher encounters a breaking change that it cannot patch then it will update the dependencies to the version with the breaking change and stop. Otherwise, it will update the dependencies the latest version of that module.
 
-If Patcher updates a dependency to a breaking version, a `README-TO-COMPLETE-UPDATE.md` is written into the folder containing the dependendency. The `README-TO-COMPLETE-UPDATE.md` file contains a release note extract for each dependency in that folder that was updated to a breaking change.
+If Patcher updates a dependency to a breaking version, a `README-TO-COMPLETE-UPDATE.md` is written into the folder containing the dependency. The `README-TO-COMPLETE-UPDATE.md` file contains a release note extract for each dependency in that folder that was updated to a breaking change.
 
 Example usage:
 ```
@@ -112,7 +112,7 @@ And in `infrastructure-live/dev` there is a dependency on `terraform-aws-vpc/vpc
 
 ![Screenshot of third party module dependency with updates available](/img/guides/stay-up-to-date/patcher/patcher-update-overview-3p-update-available.png)
 
-Patcher can update this dependency to the latest version but because there is a breaking version in between, Patcher updates to `5.0.0` and writes a `README-TO-COMPLETE-UPDATE.md` file into the folder containing the dependendency.
+Patcher can update this dependency to the latest version but because there is a breaking version in between, Patcher updates to `5.0.0` and writes a `README-TO-COMPLETE-UPDATE.md` file into the folder containing the dependency.
 
 ![Screenshot of third party module dependency usages with updates available](/img/guides/stay-up-to-date/patcher/patcher-update-usages-3p-update-available.png)
 
@@ -137,6 +137,6 @@ Here are the release notes for version v5.0.0:
 * Bump Terraform AWS Provider version to 5.0 ([#941](https://github.com/terraform-aws-modules/terraform-aws-vpc/issues/941)) ([2517eb9](https://github.com/terraform-aws-modules/terraform-aws-vpc/commit/2517eb98a39500897feecd27178994055ee2eb5e))
 ```
 
-Running Patcher again will complete the update to `5.1.1`, the `README-TO-COMPLETE-UPDATE.md` file should be read, actioned and deleted first.
+Running Patcher again will complete the update to `5.1.1`, the `README-TO-COMPLETE-UPDATE.md` file should be read, followed and deleted first.
 
 ![Screenshot of third party module dependency full up to date](/img/guides/stay-up-to-date/patcher/patcher-report-overview-3p-futd.png)
diff --git a/docs/2.0/docs/pipelines/architecture/security-controls.md b/docs/2.0/docs/pipelines/architecture/security-controls.md
@@ -144,7 +144,7 @@ The read-only plan role for delegated repositories.
 
 The `infrastructure-live-access-control` repository is vended ready to provision these roles with the configuration baked in.
 
-Enterprise customers will see pull requests opened automatically in the `infrastructure-live-access-control` repository to vend these roles for every new account vended as a delegated account. Given that delegated accounts have their own repositories that are separate from the main `infrastructure-live-root` and `infrastructure-live-access-control` repositories, these roles are used to ensure that the delegated repositories have adqueate access to the infrastructure they need to manage.
+Enterprise customers will see pull requests opened automatically in the `infrastructure-live-access-control` repository to vend these roles for every new account vended as a delegated account. Given that delegated accounts have their own repositories that are separate from the main `infrastructure-live-root` and `infrastructure-live-access-control` repositories, these roles are used to ensure that the delegated repositories have adequate access to the infrastructure they need to manage.
 
 :::note
 
@@ -160,7 +160,7 @@ The read/write apply role for delegated repositories.
 
 The `infrastructure-live-access-control` repository is vended ready to provision these roles with the configuration baked in.
 
-Enterprise customers will see pull requests opened automatically in the `infrastructure-live-access-control` repository to vend these roles for every new account vended as a delegated account. Given that delegated accounts have their own repositories that are separate from the main `infrastructure-live-root` and `infrastructure-live-access-control` repositories, these roles are used to ensure that the delegated repositories have adqueate access to the infrastructure they need to manage.
+Enterprise customers will see pull requests opened automatically in the `infrastructure-live-access-control` repository to vend these roles for every new account vended as a delegated account. Given that delegated accounts have their own repositories that are separate from the main `infrastructure-live-root` and `infrastructure-live-access-control` repositories, these roles are used to ensure that the delegated repositories have adequate access to the infrastructure they need to manage.
 
 :::note
 
diff --git a/docs/2.0/docs/pipelines/concepts/overview.md b/docs/2.0/docs/pipelines/concepts/overview.md
@@ -25,7 +25,7 @@ We also make updates directly to Terragrunt to support the functionality we want
 
 One of the things we've discovered over the years helping customers automate their infrastructure management is that it can be _very_ costly and time-consuming to build and maintain a CI/CD pipeline that can efficiently handle the complexity of infrastructure changes. Customers typically don't want to trigger an update to _all_ of their infrastructure whenever _any_ component changes, and they typically want to have related changes coordinated and rolled out correctly.
 
-A driving design goal of Gruntwork Pipelines is to allow for a minimal setup experience, followed by a very intuitive model for driving infrastructure updates. Most customers can get Pipelines configured in less than an hour, then drive all of their infrastructure changes directly via pull requests to Infrastructure as Code. Most of the time, you do not need to think about how Grutnwork Pipelines works, or how it makes decisions about what to do. You simply update your Infrastructure as Code to reflect the desired state of your infrastructure, have the pull request reviewed and merged, then Gruntwork Pipelines takes care of the rest.
+A driving design goal of Gruntwork Pipelines is to allow for a minimal setup experience, followed by a very intuitive model for driving infrastructure updates. Most customers can get Pipelines configured in less than an hour, then drive all of their infrastructure changes directly via pull requests to Infrastructure as Code. Most of the time, you do not need to think about how Gruntwork Pipelines works, or how it makes decisions about what to do. You simply update your Infrastructure as Code to reflect the desired state of your infrastructure, have the pull request reviewed and merged, then Gruntwork Pipelines takes care of the rest.
 
 ## Runs directly in GitHub Actions
 
diff --git a/docs/2.0/docs/pipelines/guides/extending-pipelines.md b/docs/2.0/docs/pipelines/guides/extending-pipelines.md
@@ -11,7 +11,7 @@ Extending Gruntwork Pipelines involves managing code in three different source c
 * `pipelines-actions` - This is where the bulk of the business logic for pipelines lives
 * `pipelines-actions-customization` - This is where a customer's custom logic primarily lives.
 
-The intention is that customers will never have to touch code that is frequently modified by Gruntwork, namely `pipelines-actions`.  Instead customers will update code references inside `pipelines-workflows` to point to custom code in another repository, so the only surface area for merge conflict/code maintaince is a scant few lines of reference change in `pipelines-workflows`.
+The intention is that customers will never have to touch code that is frequently modified by Gruntwork, namely `pipelines-actions`.  Instead customers will update code references inside `pipelines-workflows` to point to custom code in another repository, so the only surface area for merge conflict/code maintenance is a scant few lines of reference change in `pipelines-workflows`.
 
 <img alt="Diagram of Gruntwork Pipelines Repositories" className="img_node_modules-@docusaurus-theme-classic-lib-theme-MDXComponents-Img-styles-module medium-zoom-image" src="/img/pipelines/pipelines_customization_code_locations.svg" />
 
diff --git a/docs/2.0/docs/pipelines/guides/running-drift-detection.md b/docs/2.0/docs/pipelines/guides/running-drift-detection.md
@@ -30,7 +30,7 @@ Running Pipelines Drift Detection too frequently can easily eat through your Git
 
 ## Resolving Drift
 
-Drift can be resolved by either applying the commited IaC from your repository, or modifying modules until they reflect the infrastructure state in the cloud.
+Drift can be resolved by either applying the committed IaC from your repository, or modifying modules until they reflect the infrastructure state in the cloud.
 
 ### Merging The Pull Request
 
diff --git a/docs/2.0/docs/pipelines/guides/setup-delegated-repo.mdx b/docs/2.0/docs/pipelines/guides/setup-delegated-repo.mdx
diff --git a/docs/2.0/docs/pipelines/guides/terragrunt-env-vars.md b/docs/2.0/docs/pipelines/guides/terragrunt-env-vars.md
diff --git a/docs/2.0/docs/pipelines/installation/viamachineusers.md b/docs/2.0/docs/pipelines/installation/viamachineusers.md
diff --git a/docs/2.0/docs/pipelines/previous-versions/upgrading-from-ecs-deploy-runner.md b/docs/2.0/docs/pipelines/previous-versions/upgrading-from-ecs-deploy-runner.md
diff --git a/docs/2.0/reference/pipelines/configurations-as-code/index.md b/docs/2.0/reference/pipelines/configurations-as-code/index.md

Original file line number	Diff line number	Diff line change
`@@ -4,4 +4,4 @@ Gruntwork's platform is built for teams adopting OpenTofu and Terragrunt. Our pr`
`4`	`4`
`5`	`5`	`## Do I have to use Terragrunt?`
`6`	`6`
`7`		-Several Gruntwork platform products, such as [Pipelines](/2.0/docs/pipelines/concepts/overview) and [Account Factory](/2.0/docs/accountfactory/concepts/) are built explicitly ontop of features of Terragrunt and thus require that organizations adopt Terragrunt as part of their IaC platform. Other products, such as the [Library](/2.0/docs/library/concepts/overview) can be used with or without Terragrunt. We generally do advise Library customers to adopt Terragrunt, we have built Terragrunt specifically to solve problems related to orchestrating OpenTofu at scale and we can best help you achieve a successful implementation if you are using Terragrunt.
	`7`	+Several Gruntwork platform products, such as [Pipelines](/2.0/docs/pipelines/concepts/overview) and [Account Factory](/2.0/docs/accountfactory/concepts/) are built explicitly on top of features of Terragrunt and thus require that organizations adopt Terragrunt as part of their IaC platform. Other products, such as the [Library](/2.0/docs/library/concepts/overview) can be used with or without Terragrunt. We generally do advise Library customers to adopt Terragrunt, we have built Terragrunt specifically to solve problems related to orchestrating OpenTofu at scale and we can best help you achieve a successful implementation if you are using Terragrunt.
Original file line number	Diff line number	Diff line change
`@@ -8,7 +8,7 @@ Example usage:`
`8`	`8`	`patcher report prod`
`9`	`9`	```
`10`	`10`
`11`		-The report command outpust a list of module dependencies in JSON format to `stdout`, for example:
	`11`	+The report command outputs a list of module dependencies in JSON format to `stdout`, for example:
`12`	`12`	```json
`13`	`13`	`[`
`14`	`14`	`"gruntwork-io/terraform-aws-monitoring/logs/load-balancer-access-logs",`