Using the latest GitLab (not admin so not sure of the version, but know it is upgraded regularly, generally within short days of a new release).
I have a pipeline for deploying some development infrastructure using Terraform. The pipeline can be fairly straightforward. The essential pipeline would consist of a job that invokes terraform plan
, followed by a job that invokes terraform apply
.
For those not familiar with Terraform: the first command compares known infrastructure state to configuration, and determines what changes, if any, need to be performed. The second command applies those changes.
I like to gate the apply
job with when: manual
to give me a chance to review the planned changes and ensure a mistake won’t inadvertently destroy something.
So that’s the situation. Here’s the problem:
terraform plan
has three possible results:
- failure, for whatever reason
- success where changes are identified
- success where it is identified no changes are necessary.
The first and second possibilities have a clear implementation in CI. If failure, the pipeline fails. If there are changes, go on to the apply
job and block on waiting for me to verify the output of the plan job.
The third is where this breaks down. Conditionals such as rules: if
apply to variables known at the beginning of the pipeline: either defined in .gitlab-ci.yaml
, as CI variables, or predefined. I can’t see a way to predicate a job on variables set by a previous job.
I can alter the execution of the apply job based on such a variable, such that I could do:
plan:
script:
- echo "DOIT=yes" >> shouldi.env
artifacts:
reports:
dotenv: shouldi.env
apply:
script:
- if [ "$DOIT" != "yes" ]; then exit; fi
- ...do the stuff...
The above will not do anything if DOIT
isn’t set to yes
, but I would prefer the job were skipped instead. Moreover, this breaks the when: manual
workflow–the pipeline would stop waiting on input even if there was nothing left to do.
I believe the reason it’s like this is so GitLab can construct a DAG of the pipeline, but if anybody has an idea for how I could address this problem, please let me know.
Cheers,
Drew.