Terramate selects stacks for execution with parent configuration changes

[tw-kelvin]

Hi, thanks for developing and maintaining Terramate 🥳

We would like to know if you plan to detect parent terramate configuration changes which influence the generation of stack's code.

Our Setup

We use Terramate to generate Terraform code for stacks following the same pattern. This leads to a project structure as

./config.tm.hcl # root config
./stacks/config.tm.hcl 
./stacks/pattern-a/config.tm.hcl # config that defines generated codes for child stacks
./stacks/pattern-a/stack-a/config.tm.hcl
./stacks/pattern-a/stack-b/config.tm.hcl

Here ./stacks/pattern-a/config.tm.hcl defines with generate_hcl which Terraform code will be generated in stack-a and stack-b and the configurations ./stacks/pattern-a/(stack-a|stack-b)/config.tm.hcl define the stack specific globals that configure values for the code generation.

We are not pushing the generated code to our git repository (because it leaves room for manual mistakes). Instead we run terramate generate in our CI/CD pipeline.

Our Issue

When we change something in the configuration about the code that we generate in ./stacks/pattern-a/config.tm.hcl then terramate (with --changed) does not select the stacks ./stacks/pattern-a/(stack-a|stack-b) for execution (because the git diff does not reflect the changes) even though the code that will be generated changes.

Workaround

I am currently only aware of the workaround to set the central configuration (./stacks/pattern-a/config.tm.hcl) in every stack (./stacls/pattern-a/(stack-a|stack-b)) as watch = [ "../config.tm.hcl" ] to make sure that if the config changes we also trigger the execution of the stacks.
Is there a more elegant approach?

[mariux]

Hi @tw-kelvin

Thank you for your feedback.

Indeed we - at the current state of development - recommend to always check in code for several reasons:

• review-ability - it is easier for reviewer to understand what a config change is actually causing in the generated code.
• debugging - Terraform errors reference a specific line of code that caused a failure or conflict, which is hard to relate to when code is not existing.
• reliability - Terramate is under heavy development and if we accidentally introduce a regression or bug it is easier to detect when code unexpectedly generated wrong.

Those are just a few examples but maybe the most important ones.

That said, of course we are also working to improve the situation e.g. to be able to point the user to the exact Terramate locations that caused a specific error in a generated Terraform line.

Another idea we have is to introduce checksums that can be committed instead of committing the actual code and that can be used to validate the code generated on the fly is matching a tested expectation. (This file could also be consulted for change detection improvements.)

And last but not least of course improve the change detection to cover the use case you presented.

just watching the config file is indeed a nice idea to work around the missing support and i must admit that at the current state it is the best idea i know.

We are currently working on features to identify which globals are actually used in a stack and where they were set. Afaik we already know the "where is a global coming from" part but we are not making much use of it as of today.

I am sorry but we can't give any ETA of support for you use case at the moment.
But it is on the roadmap.

And we highly recommend to check in the generated code as of today for the reasons stated above.

A website for terramate is currently in development too, where we will share more details about roadmap and upcoming features and finally a full documentation of all the features available.

p.s: Maybe the team can come up with other solutions that are less manual cc @i4ki

[i4ki]

Hi @marius @tw-kelvin

If the terramate run --changed only happens in the CI as well, then if executing the sequence below in the CI:

$ git checkout -b ci-run-changed
$ terramate generate
$ git commit -a -m "changed files"
$ terramate run --changed -- cmd

it would work, no?

The problem with using stack.watch is that it will mark the stacks as changed even if the generated files didn't change as the result of changing the watched file...