Expose component, stack, and tf workspace as tags and `TF_VAR` env vars

[nitrocode]

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

Describe the Feature

Expose component, stack, and tf workspace as TF_VAR env vars

I'd like to add TF_VAR inputs to receive the following env vars

TF_VAR_atmos_base_component
TF_VAR_atmos_component
TF_VAR_atmos_stack
TF_VAR_atmos_terraform_workspace

Expected Behavior

For a base component of eks/cluster (type: abstract) and a component eks-blue/cluster (type: real) planned against uw2-dev should return the following values

TF_VAR_atmos_base_component=eks/cluster
TF_VAR_atmos_component=eks-blue/cluster
TF_VAR_atmos_stack=uw2-dev
TF_VAR_atmos_terraform_workspace=uw2-dev-eks-blue-cluster

For a component of ecr (type: real) without metadata using type: abstract and planned against uw2-dev should return the following values (or similar)

TF_VAR_atmos_base_component=ecr
TF_VAR_atmos_component=ecr
TF_VAR_atmos_stack=uw2-dev
TF_VAR_atmos_terraform_workspace=uw2-dev-ecr

It would be nice to append the tags input with the above as well

tags:
  ATMOS_BASE_COMPONENT: ecr
  ATMOS_COMPONENT: ecr
  ATMOS_STACK: uw2-dev
  ATMOS_TERRAFORM_WORKSPACE: uw2-dev-ecr

Use Case

I'd like to

• add the above information as tags
• create unique ssm parameters using the path /atmos_stack/atmos_component/key

Describe Ideal Solution

using TF_VAR env vars

Alternatives Considered

N/A

Additional Context

N/A

[nitrocode]

cc @aknysh @osterman @Gowiem thoughts?

[Gowiem]

@nitrocode I'm all for it -- I think this would be useful information in AWS resource tags as well to help pinpoint where resources are coming from for new team members who may be unaware. Considering that... any plans to pull these values into context.tf to support tagging all resources with this information? We could accomplish that easily through an updated introspection.mixin.tf.

Regardless, 👍

[osterman]

I believe we already expose these as general variables. What about using an existing provider:

https://registry.terraform.io/providers/tchupp/env/latest/docs/data-sources/variable https://registry.terraform.io/providers/shekhar-jha/env/latest/docs/data-sources/env_os

There's a dozen or more of these env var terraform providers.

[osterman]

Alternatively, I'd be open to supporting the template substitutions we support else where (e.g. stack_name_pattern) so you can define your own ENV vars or tags. But building in this opinionated null-label/context conventions into atmos IMO is breaking boundaries. Atmos should be a general purpose tool, not one designed specifically for cloud posse modules.

[nitrocode]

I suppose an existing provider would work. It would be easy enough to add the provider to a mixin and then add the mixin to each component. The down side of that would be that every component would rely on a custom 3rd party provider

Building your own ENV vars would be cool. I believe Atlantis has support for this e.g.

https://www.runatlantis.io/docs/custom-workflows.html#step

workflows:
  default:
    plan:
      steps:
        - env:
            name: TF_VAR_terraform_repository
            command: 'echo "github.com/${HEAD_REPO_OWNER}/${HEAD_REPO_NAME}"'
        - env:
            name: TF_VAR_terraform_repository_dir
            command: 'echo "${REPO_REL_DIR}"'
        - env:
            name: TF_VAR_terraform_version
            command: 'echo "${ATLANTIS_TERRAFORM_VERSION}"'

Maybe an implementation like this would be more flexible?