Summary
The new high/normal/low run priority levels work well day to day. What's missing is a way to set priority automatically based on how wide a change's blast radius is, so that a commit triggering hundreds of stacks doesn't queue ahead of targeted, single-stack changes.
Problem
During normal operations, built-in prioritization keeps plans moving quickly. Even large volumes of drift detection runs don't cause meaningful delays.
The problem shows up when a PR or merge touches shared configuration that fans out to dozens or hundreds of stacks. Those runs build large queues that block unrelated, targeted changes behind them. In one recent case, a single commit touching terragrunt/regions/multi-tenant/tenancy.hcl triggered almost 800 runs.
This comes from how our Terragrunt stacks are structured. Each stack watches its own project root plus shared config files higher up in the hierarchy, for example:
project_root = "terragrunt/regions/all/gcp-log-metrics/s4s2"
additional_project_globs = [
"terragrunt/regions/all/gcp-log-metrics/*.hcl",
"terragrunt/regions/all/s4s2.hcl",
"terragrunt/regions/all/tenancy.hcl",
"terragrunt/regions/regions.hcl",
]This is correct behavior, since a change to a common setting higher up can affect the stack. But with hierarchies containing hundreds of stacks, one edit to a shared file can start concurrent runs across all of them.
Proposed solutions
Either of these would solve it, and they could complement each other.
Option 1: Priority policy based on affected stacks. Allow a policy (auto-attached or manually attached) that can see the set of stacks affected by a commit or PR and assign run priority. For example: if a change triggers more than N stacks, move those runs to low priority. Spacelift support suggested this approach.
Option 2: Priority per project glob. Allow priority to be set on the project root and on each entry in additional_project_globs, so that the matched path determines the run's priority. Using the example above:
Glob depth maps closely to run count in our setup, so this would be a simple, declarative way to get the right behavior without needing to count stacks at runtime.
Desired ordering
High fan-out runs should drop below targeted changes but ideally still stay above drift detection:
High → Normal → Low (high fan-out changes) → Drift detection
Impact
Targeted, single-stack changes would stay fast even while a large fan-out change is working through its queue, which is when unblocked changes matter most.