[FEATURE] Allow use of env variables inside in stacks too

[vikas027]

Is your feature request related to a problem? Please describe.

I am working on Azure and have a multi-subscription architecture. If I am sitting on root and I run terramate run terraform init command, it traverses down to each directory and executes the command.

For example, if my stack structure is like below, I want to use environment variables (ARM_SUBSCRIPTION_ID, ARM_TENANT_ID, ARM_CLIENT_ID and ARM_CLIENT_SECRET) specific to an environment.

envs/dev/terraform_init/stack.tm.hcl
envs/prod/terraform_init/stack.tm.hcl

Describe the solution you'd like

Any way of picking environment variables would be good, maybe something like this

stack {
  name        = "terraform_init"
  description = "Initialize Terraform Backend"
  id          = "xxxx-yyy"

  tags = [
    "dev",
  ]

  env_vars = [
    ARM_CLIENT_SECRET = "${env.DEV_ARM_CLIENT_SECRET}"
  ]
}

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

As of now, I am using these commands to individually run each of the stacks after setting up AZ subscription

source dev.env
terramate run -C envs/dev terraform init

source prod.env
terramate run -C envs/prod terraform init

[soerenmartius]

Hi @vikas027,

Thanks for requesting this. We have item on our product roadmap to make environment variables configurable for stacks similarly to the existing runtime configuration.

QQ: Would you expect those environment variables to be inherited and available for all nested stacks as well?

Thank You

[vikas027]

Hey @soerenmartius ,

Yes, it would be good to inherit an environment variable and inherit it in all stacks. This will be helpful in my situation where I want to keep the code DRY in a multi-account / region setup.

[soerenmartius]

Hey @soerenmartius ,

Yes, it would be good to inherit an environment variable and inherit it in all stacks. This will be helpful in my situation where I want to keep the code DRY in a multi-account / region setup.

That makes sense, thanks for your feedback! I'll discuss this with the team and get back to you.

[mariux]

Hi @vikas027,

So we planned the following change in defining the run time environment:

We will allow to set terramate.config.run.env variables at any level of the hierarchy. Inheritance will be similar to globals:

• any variable defined on a higher level will be inherited to the full subtree including nested stacks.
• any variable redefined on the same level will conflict
• any variable redefined on lower levels will overwrite previous definitions
• all values will be only evaluated on stack level.
• any null value will be treated as unset and not variable will be exported
• to unset a variable on a lower level you can assign unset value or null

Before we start, could you confirm if this would solve your problem?

[g13013]

@mariux the env block would be under terramate.config.run.env or stack.run.env ? the later makes more sense to me as it clearly implies that it's scoped to the stack.

[soerenmartius]

@mariux the env block would be under terramate.config.run.env or stack.run.env ? the later makes more sense to me as it clearly implies that it's scoped to the stack.

Using terramate.config.run.env is already possible in stacks and any other point in your hierarchy since v0.8.0. It will be inherited for nested stacks though. Please take a look at https://terramate.io/rethinking-iac/terramate-v0-8-0/ if you'd like to learn more about it!

Perhaps we could think about adding stack.run.env to define environment variables for one specific stack only. I'll discuss this with the team.