Skip to main content

Bulk trigger with runtime config

Feature Requests

It’s possible to trigger an individual stack with a runtime configuration but not when doing a bulk trigger. This would be useful as in the case of setting a consistent environment variable (e.g. for terragrunt) to be provided to multiple triggered stack runs from bulk actions.

Workaround
Status: 🔭 Discovery2 comments

This request was merged into another request

Comments2

  • Black Breeze

    •

    Dec 16, 2025

    Thanks for bringing this up. Can you please share a detailed use case? I always thought of runtime overrides as sort of one-off operations of last resort, not something you’d want to trigger in bulk. So I’m intrigued.

    • Yellow Mirror

      •

      Dec 16, 2025

      Absolutely. It’s not something that’s great to have to do but has it’s uses. Today we use terragrunt run-all, and in the future might do similar with vanilla terraform or opentofu. The specific use case regardless but specific here for terragrunt is as follows:

      We have many equivalently structure terragrunt directory structures which represent our various tenants:

      tenant-a/

      network/terragrunt.hcl

      database/terragrunt.hcl

      kubernetes-cluster/terragrunt.hcl

      …

      tenant-b/

      network/terragrunt.hcl

      database/terragrunt.hcl

      kubernetes-cluster/terragrunt.hcl

      …

      tenant-c/

      network/terragrunt.hcl

      database/terragrunt.hcl

      kubernetes-cluster/terragrunt.hcl

      …

      Normally we just use terragrunt run-all and plan / apply everything. Things like auto-deploy and drift detection helps us fight unapplied changes and drift. Each stack’s project root points to the top level tenant directory (e.g. tenant-a). Our terragrunt.hcl configurations include layered configuration, which includes inputs from hcl files which reside in directories which sit higher in the filesystem that these tenant directories, and thus the stack trigger behavior is unaware of changes to those. I suppose on thing we could do is to write a custom trigger but in practice it might be taking a shotgun approach to what the human authors see as more of a surgical change.

      That brings us to the specific use case, where we’d use the terragrunt —queue-include-dir and —queue-strict-include options. This is expressed with runtime configuration using environment variables. Example:

      environment:

      TG_QUEUE_INCLUDE_DIR: kubernetes-cluster

      TG_QUEUE_STRICT_INCLUDE: true

      What this achieves is a speed up, where our tenant oriented stacks have more modules (and growing) than the 3 you see listed in the examples above.

      Hope this helps to paint the picture.