Add Terraform build job to environment and document destroy
What does this MR do and why?
This change set proposes that the build
job from the Terraform template (which runs a terraform plan
) is
part of the environment the deploy
job is associated with - just that the action
is prepare
.
IMHO, the prepare
action
is the closest match to what it does - planning the environment.
What about the stopping the environment?
To close the "integration circle" with Terraform and GitLab environments it would be nice to have the stop action properly configured.
However, it's not really clear if we should do this, the reason is that there is only a .terraform:destroy
job in the job template, but none in the pipeline template which would inherit from it. Environments today are ONLY part of the pipeline template.
The destroy
job is in the job template, because most people don't really destroy their environments that often - they are long-running environments, like production. Having a manual destroy
job in the pipeline template may not be desired for every pipeline.
What we could do is introduce a special env variable to control the creation of a destroy
job in the pipeline template which would be evaluate in the rules:if
block and set via manual pipeline trigger when someone really wants to destroy the environment.
I also think that if we'd have an environment variable controlling the destroy
job we could also change the build
job to ran a terraform plan -destroy
and omit the deploy
job.
However, this also has the downside that the on_stop
action for the deploy
job cannot be linked to the destroy
job which would conditionally exist via that variable.
I think we face a dilemma here, because GitLab environments together with CI/CD pipelines are not flexible enough for this use case.
For now, I'm going to document how the destroy
job can be associated with the environment.
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.