Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions docs/2.0/docs/pipelines/concepts/overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,15 +17,17 @@ Gruntwork is the creator and maintainer of [Terragrunt](https://terragrunt.grunt
- `terragrunt plan`
- `terragrunt apply`
- `terragrunt destroy`
- `terragrunt run-all`
- `terragrunt run-all plan`
- `terragrunt run-all apply`
- `terragrunt run-all destroy`
Comment on lines 17 to +22
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Update to the current terragrunt run --all syntax

The bullets still reference the deprecated run-all subcommand. To keep the docs aligned with modern Terragrunt usage, please switch these examples to terragrunt run --all plan|apply|destroy (matching the CLI evolution noted earlier).
Based on learnings

🤖 Prompt for AI Agents
In docs/2.0/docs/pipelines/concepts/overview.md around lines 17 to 22, the
examples use the deprecated terragrunt subcommand "run-all"; update the three
bullets that list "terragrunt run-all plan", "terragrunt run-all apply", and
"terragrunt run-all destroy" to the current syntax "terragrunt run --all plan",
"terragrunt run --all apply", and "terragrunt run --all destroy" (or a single
combined example shown as "terragrunt run --all plan|apply|destroy"), ensuring
spacing and hyphenation match the modern CLI form used elsewhere in the docs.


Gruntwork actively contributes to Terragrunt, ensuring it supports features critical to Gruntwork Pipelines.

## Simplifies CI/CD Complexity

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 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.
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 Gruntwork 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 in GitHub Actions or GitLab CI

Expand Down