Break affected files down into new, modified, deleted
We make use of
https://github.com/spacelift-io-examples/dynamic-spacelift-stacks-example/tree/main to create stacks for all of our terragrunt projects in a monorepo.
Given hundreds of terragrunt projects exist in the monorepo, we only trigger the administrative job if affected files contain something relating to the administrative stack.
As a result, when new Terragrunt projects are added, they aren’t picked up—the administrative stack is not modified, but a new terragrunt.hcl file is introduced.
It would be neat if it were possible to break the affected files section of the policy input into new, modified and deleted so we could have a policy trigger the administrative stack if a new terragrunt.hcl is introduced or a terragrunt.hcl is deleted.
Log in to comment and vote
Comments1
Black Breeze
May 8, 2025
Thanks for the thoughtful request!
You’re right that today’s policy input doesn’t break down affected files into “new, modified, deleted”—mainly because pushes can include multiple commits, making it hard to determine net file state. For example, one commit might delete a file, another adds it back, and a third modifies it—all in a single push. The result is ambiguous.
Rather than trying to classify diffs post hoc, we’d suggest a simpler, more reliable approach: using sentinel files.
If each Terragrunt project includes a .trigger or .version file (e.g., next to the terragrunt.hcl), you could:
Update that file when a new project is introduced
Bump its contents (e.g., version number or timestamp) to signal meaningful changes
Write a push policy that triggers the admin stack when any of those sentinel files are affected
This makes the signal explicit and under your control—no need to reverse-engineer diff types or guess developer intent. It also integrates cleanly with your existing monorepo setup and dynamic stack generation.
Happy to share a quick policy snippet if helpful!