Merge branch 'main' into opentofu-migration

Author: josh-padnick

custom-dictionary.txt

@@ -54,4 +54,9 @@ projectprefix
 GOVCLOUD
 rollouts
 myvars
-myfile
+myfile
+gruntwork-io
+minamijoyo
+tfupdate
+hcledit
+self-hosting

docs/2.0/docs/accountfactory/guides/drift-remediation-with-async-module.md

@@ -134,7 +134,7 @@ For `_envcommon/landingzone/root-pipelines-apply-role.hcl`, ensure that you have
    }
 ```
 
-For `_envcommon/landingzone/root-pipelines-plan-role.hcl`, ensure that you have at leasat the following permissions:
+For `_envcommon/landingzone/root-pipelines-plan-role.hcl`, ensure that you have at least the following permissions:
 
 ```hcl
     "CloudWatchEventsReadOnlyAccess" = {
@@ -175,7 +175,8 @@ For `_envcommon/landingzone/root-pipelines-plan-role.hcl`, ensure that you have
      actions   = [
        "states:List*",
        "states:Describe*",
-       "states:GetExecutionHistory"
+       "states:GetExecutionHistory",
+       "states:ValidateStateMachineDefinition"
      ]
      effect    = "Allow"
    }

docs/2.0/docs/accountfactory/tutorials/modify-account.md

@@ -29,9 +29,6 @@ The table below lists common AWS account operations and provides guidance on whe
 | Update account admin user in Account Access IAM Identity Center                                                               | ✅ (recommended) | ✅ (discouraged)       |
 | Granting additional users access to accounts in AWS IAM Identity Center                                                       | ✅ (recommended) | ✅ (discouraged)       |
 
-| Granting additional users access to accounts in AWS IAM Identity Center                                                       | ✅ (recommended) | ✅ (discouraged)       |
-
-
 ### Updating the account through the new AWS account request file
 
 You can update specific attributes of an AWS account by modifying the corresponding account request file in the `_new_account_requests` directory. Follow the steps below to update specific attributes:

docs/2.0/docs/patcher/concepts/index.md

@@ -1,9 +1,41 @@
 # What is Gruntwork Patcher?
 
-Gruntwork Patcher automates the process of keeping your infrastructure code ([Terragrunt](https://terragrunt.gruntwork.io/) and [OpenTofu](https://opentofu.org/)) up to date, including applying patches to ensure compatibility with backward-incompatible module releases.
+Gruntwork Patcher automates the process of keeping your infrastructure code ([Terragrunt](https://terragrunt.gruntwork.io/), [OpenTofu](https://opentofu.org/), and [Terraform](https://terraform.io)) up to date, including applying patches to ensure compatibility with backward-incompatible module releases.
+
+We use the term "Patcher" to refer to the [Patcher CLI](https://github.com/gruntwork-io/patcher-cli), the public [Patcher GitHub Action](https://github.com/gruntwork-io/patcher-action), and the collection of tools (like [Terrapatch](https://github.com/gruntwork-io/terrapatch-cli)) that enable Patcher to be useful.
+
+## Why use Patcher?
 
 Manually identifying updates and assessing whether they can be safely applied can consume significant engineering time for each module dependency. Patcher eliminates this inefficiency by streamlining the update process.
 
-You can use Gruntwork Patcher to manage dependencies on the Gruntwork IaC Library, which includes patches for recent breaking changes to Gruntwork modules. Patcher also supports updating dependencies for your own modules or open-source projects, using semantic versioning to identify safe updates and highlight those that need manual review.
+Patcher supports keeping any set of OpenTofu/Terraform modules up to date, whether they be your in-house modules, third-party open source modules, or modules from the [Gruntwork IaC Library](/2.0/docs/library/concepts/overview).
+
+Patcher specializes in keeping infrastructure code up to date and currently supports automatic updates for:
+
+- OpenTofu modules
+- Terraform modules
+- Terragrunt units
+- Terragrunt stacks
+
+## Two update modes
+
+When most teams think about updating their infrastructure code, there are two core use cases they look to solve:
+
+1. **Legacy upgrade.** You wish to take a repo or set of files that are significantly out of date and bring them up to date with the latest OpenTofu/Terraform module versions.
+2. **Ongoing updates.** You wish to streamline the process of keeping a repo or set of files up to date over time.
+
+Patcher can help with both of these use cases.
+
+For legacy upgrades, the Patcher CLI offers an [interactive mode](/2.0/docs/patcher/guides/update) where you can browse all modules in the current working directory and below, browse available updates, and upgrade modules one at a time. We've found this approach works well with a modest set of updates, however for significantly out of date repos or files or a large number of files, you may wish to consider alternative approaches.
+
+For ongoing updates, you can use Patcher in conjunction with our [published GitHub Action](https://github.com/gruntwork-io/patcher-action) to automatically scan your repo's modules and [open pull requests](/2.0/docs/patcher/guides/ongoing-updates) with updated module versions. Opening one pull request for every update can get cumbersome, so Patcher also supports a variety of [grouping modes](/2.0/docs/patcher/concepts/grouping) that allow you to streamline your workflow.
+
+## How does Patcher work?
+
+Patcher handles both non-breaking and breaking changes. For non-breaking changes, for the [Gruntwork IaC Library](/docs/2.0/docs/library/concepts/overview.md), Patcher uses a set of pre-generated changelog files to identify the "next safe change," enabling upgrades to automatically bypass "empty" version upgrades where a module is available at a newer version but in fact has had no actual file changes. Upon request, we can work with you to implement these pre-generated changelogs in your own organization.
+
+For breaking changes, Patcher offers a systematic approach to doing code transformations -- we call these "patches" -- so that module consumers can automatically apply breaking changes to their modules. Or if Patcher detects a breaking change but a patch does not exist, Patcher updates the relevant module to the next breaking change and generates a `README` file in the folder with the updated file that outlines the release notes and details the breaking changes. Users review the `README`, address any necessary actions, and remove the file before re-running Patcher.
+
+## Supported integrations
 
-Gruntwork Patcher provides a clear, README-driven workflow for breaking changes without available patches. When Patcher detects breaking changes, it updates the relevant dependency to the version containing those changes and generates a README file in the folder with the updated file. This README outlines the release notes and details the breaking changes. Users must review the README, address any necessary actions, and remove the file before rerunning Patcher.
+Patcher currently works for GitHub, GitHub Enterprise, and GitHub Enterprise self-hosted.