Ensure Consistency between Environment Variables during Deployment and Teardown

GitLab CI/CD
, ,
1

So I am writing a Deployment and Teardown Job and those use Environment Variables from the Gitlab variable store. Now the Teardown Job might be started much later than the Deployment, so the question is: Can I assume that the Environment Variables between the Deployment and Teardown will stay the same? Would a change to the Variable store between Deployment And Teardown have an effect on the Job? Or are Variables “frozen” when the Pipeline is created?

I am thinking this is not the case since you can rerun pipelines. (Presumably with different environment variables)

So if that is not the case I probably have to cache the environment variables somehow - maybe in an artifact. Although I am currently planning to use environment variables for tags - since that allows for an easy change from one server to the next by simply changing the global tag environment variable and all the project would use the runner on the new server during the next run. But that introduces this consistency problem since I probably can not use artifacts to define tags…

EDIT: it appears I am not allowed to use environment variables for tags (Where variables can be used | GitLab)

2

Hello Felix,

Short Answer

I tested out your concern, and by default, there is no “consistency” between the environment variables and different jobs.

  • Sample build job with DEFINED_CI_VARIABLE set,
  • Sample deploy job manually triggered after I had modified the CI/CD variables.

If there are variables that may change, you could try to use an artifacts:reports:dotenv file to save the variables you need.
Be careful that this does not contain secrets as it can be downloaded as a job artifact by users who have access to jobs but may not have access to CI/CD variables.

Long Answer

In an ideal deployment pipeline, your CI/CD variables should only contain secrets to access the resources/APIs required for deployment and teardown. Everything else that is configuration that needs to be consistent between a deployment and teardown should be committed into your project.

The best way to handle cases like deploying/destroying infrastructure would be with tools like terraform which create a state file that keeps track of the resources to update/destroy.