Spacelift triggers on every change resulting in many no-change plans

[nitrocode]

trafficstars

Have a question? Please checkout our Slack Community or visit our Slack Archive.

Describe the Feature

Problem: Spacelift triggers on every root stack change

Option 1: commit all the spacelift stacks using stacks_generated/ and keep rego proposed/tracked policy

I'd like a way for atmos to read the atmos.yaml configuration's stacks.base_path e.g. ./stacks and generate a new file for each component of its full stack yaml in a ./stacks_generated directory which is then committed into the repo but never modified manually. The files could be generated on a pre-commit hook and a github action.

If Spacelift's rego policy then looked at ./stacks_generated instead of ./stacks, it would then only trigger on component stacks that were added/modified instead of their root stacks. This would substantially reduce the number of Spacelift runs.

This functionality already exists via the describe subcommand

atmos describe component vpc --stack mdev-use2-sbx01

Pros

• It would work

Cons

• Nobody would enjoy dealing with auto committed files
• The bot that auto committed would require write access
• The repo settings would need to be loosened

Option 2: Use spacelift_run instead of rego proposed/tracked policy ?

Throw out the projects_affected rego block and use the spacelift_run resource to trigger a stack if the tfvars (mounted file)'s hash has changed.

Pros

• It would work

Cons

• May lose out on some nice features with rego

References

• https://github.com/cloudposse/terraform-spacelift-cloud-infrastructure-automation/blob/d08afd415a1814d1d64429371633640e60fe523d/catalog/policies/git_push.tracked-run.rego#L75-L85

[osterman]

Please start with a problem statement

[nitrocode]

@osterman right. I updated it with the problem statement.

[osterman]

We've implemented a workaround using GitHub Actions. Use https://github.com/cloudposse/github-action-atmos-affected-trigger-spacelift together with specially crafted policies to trigger only affected stacks based on comments in the PR. There's no way to fix this natively in Spacelift, unless the introduce some way to run an external command to influence affected stacks. No such functionality is planned by Spacelift. We're going to close this issue for now, as there's nothing else we can do.