terramate

terramate copied to clipboard

Is your feature request related to a problem? Please describe. It would be handy to have the possibility to override globals using env vars (similar to TF_VAR_variable) or the CLI. Something like TM_GLOBAL_variable or terramate run --global=key=value could work.

A use case could be differentiating between local-dev and CI (most CI/CD systems expose a CI=true env var, which could be used for generating the backend for local-dev and CI.

Let me know what you think :)

Hi @FalcoSuessgott .. thanks for sharing. We already have this in our internal backlog as this was already requested in our community discord at some point.

Happy to track progress and ideas here as well. Sadly we can not provide an ETA atm.

Well as a workaround I guess you can just export any env var and then use it with ${env.<ENV_VAR_NAME} lol

Well as a workaround I guess you can just export any env var and then use it with ${env.<ENV_VAR_NAME} lol

I think this is only possible in the terramate.config.run.env block. https://terramate.io/docs/cli/configuration/project-config#the-terramate-config-run-env-block

Any update on this ? for now it doesn't make any sense to no be able to override globals with variables or even use the env. inside generate_hcl and generate_file and globals ! for instance, in CI, without variables we would be required to generate a file with the globals using the shell !! which completely renders generate_hcl and generate_file useless !

@g13013

So far all our tests rendered code generation unusable when depending on a users environment. in collaboration people did not have the same environment and code generation was thus creating random results based on the user, which is expected.

To understand your use case better, could you share how this will help you and explain your use case a bit?

When using terraform, you can export TF_VAR env variables to influence the execution of terraform. Which is the current recommended way to do run time specific logic.

On the initial request, the recommendation today would be to have a local-env.tm.hcl setting globals as desired and adding it to .gitignore to only execute it locally. Here you could either import a fixed set or just set globals as desired. Those can trigger generation of Terraform overrides which are by already excluded in some default .gitignore setups e.g. on GitHub.

In addition to overrides partial backend configuration in combination with TF_CLI_ARGS can used to solve the use case of using different configs for a backend.

Hi @mariux, thanks for the reply.

In our setup we are using a custom wrapper tool that does a lot of heavy lifting, one of it's capabilities is the ability to switch between environments for a single terraform call, Terramate will use global.environment which defaults to prod, to generate some files accordingly. We would like to be able to do wrapper dev plan.

In CI this ability is even more important, whatever the values are in the code, I would like to be able to enforce certain values.

Hi :), Any update on this ?

This is much needed feature as we want to change the behavior at runtime! Terraform has this ability and Terramate needs it even more !

For now I am using a script to create a tm.hcl file containing the global to achieve this and this is not convenient in the long run!

This is something we need massively, currently having to create a tm.hcl on CI which is far from ideal!

Hey folks, we are currently looking at this and will come up with a solution fairly soon!

@soerenmartius any update on this? 😄