Jobs conditional on results of output of previous job

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.

Have you tried rules:variables?

Thanks for the tip–I read this documentation about it with interest as well as the original issue which is more informative on use cases. It seems to be geared more for other conditionals and I’m curious that the applicability to job control logic isn’t addressed one way or another in the issue description or discussion, that I can see.

I might request it to be enabled in the new year on our instance and mess around with it.