Open 0xch4z opened 2 years ago
I'm not sure if this can help, but as an alternative solution you may just run a script before plan/apply
when .terraformrc
is executed it's calling different files based on the namespace and stage.
You should be able to load default environment variables this way as well
plan:
steps:
- env:
name: STAGE
command: echo ${PROJECT_NAME} | cut -d '_' -f 2-
- env:
name: NAMESPACE
command: echo ${PROJECT_NAME} | cut -d '-' -f 2- | cut -d '_' -f 1
- env:
name: COMMENT_ARGS
command: echo "${COMMENT_ARGS//\\/}" | tr ',' ' '
- run: rm -rf .terraform/* && rm -rf .terraform.lock*
- run: git config --global credential.helper git-credential-helper.sh
- run: >-
source .terraformrc &&
terraform init -input=false -no-color &&
terraform workspace select ${STAGE} &&
Problem
Currently the only way to dynamically configure your environment for running a workflow is by using the special
env
andmultienv
steps in yourplan
andapply
configuration respectively.I've found there is very rarely a case where the same environment variables needed to run
terraform plan
aren't also needed in when runningterraform apply
, meaning you must duplicate your environment configuration in two places.While framing environment configuration as an imperative "step" is neat, most of the time order doesn't matter. Additionally, when you have a need for many environment variables to be set based on complex commands, this becomes unmaintainable.
I guess there is the argument that
multienv
can be used to execute a script to carry out the complex environment setup, but duplication across both ofplan
andapply
is still needed and maintaining a large script pulling values from various places is less than ideal.Proposed Solution
Allow specifying environment variable bindings at a workflow-level. This means that there is an implicit
env
step preceding any steps in both theplan
andapply
steps.