CI: Run or trigger pipeline - allow to pass an optional commit SHA along the ref
Background
As a workaround of gitlab-org/gitlab-ce#28592, I implemented a hacky mechanism to run two automatic pipelines from within one .gitlab-ci.yml
by making use of:
- triggers with custom variables
- using
only:variables
syntax to execute the correct jobs in each pipeline
.dev-job: &dev-job
<<: *virtkick
only: &dev-job-variables
variables:
- $OPS == null
.ops-job: &ops-job
<<: *virtkick
only: &ops-job-variables
variables:
- $OPS
trigger-ops-pipeline:
stage: dev-third
<<: *dev-job
image: appropriate/curl
script:
- curl -X POST --form "token=$CI_JOB_TOKEN"
--form "ref=$CI_COMMIT_REF_NAME"
--form "variables[OPS]=true"
--form "variables[VERSION]=$CI_PIPELINE_ID"
https://example.com/api/v4/projects/8/trigger/pipeline
image-tidy:
stage: dev-third
<<: *dev-job
chart-build-lde:
stage: ops-first
<<: *ops-job
Here's a visualization of how this hackery works:
Problems
Before trigger-ops-pipeline
job is triggered, one can push another change to the same branch. As a result, the triggered pipeline will checkout a different version of code!
Goal
Code for pipeline 8241 (that I triggered within pipeline 8240) should be the same as pipeline 8240.
Proposal
Allow to pass an optional Commit SHA to the trigger. Have GitLab Runner check out the given ref and commit.
- curl -X POST --form "token=$CI_JOB_TOKEN"
--form "ref=$CI_COMMIT_REF_NAME"
--form "sha=$CI_COMMIT_SHA" # <---------- IT'S HERE!
--form "variables[OPS]=true"
--form "variables[VERSION]=$CI_PIPELINE_ID"
https://git.dreamhost.com/api/v4/projects/8/trigger/pipeline
This would check out the ref first, then git reset --hard
to the requested SHA.
The UI would change to:
Workaround
UI: no workaround available.
Trigger: pass --form "variables[COMMIT_SHA]=$CI_COMMIT_SHA"
in triggering job, and perform git reset --hard $COMMIT_SHA
in triggered job. However, this solution is dirty. $CI_COMMIT_SHA
will point to an invalid SHA. Even if overridden inside script
with export CI_COMMIT_SHA=$COMMIT_SHA
, all substitution that occurs before script eval will be wrong. Use of dynamic image names like image: my-image:commit-$CI_COMMIT_SHA
isn't possible anymore. Also, docker:latest
image that I use a lot doesn't have git
binary, making git reset --hard $VERSION
challenging.
Conclusion: consequences of workarounds are too harsh, so the feature proposal is mandated.
Links / references
~"feature proposal" ~"CI/CD"
~"Accepting Merge Requests"?
CC @markglenfletcher @markpundsack @bikebilly @jlenny @ayufan @grzesiek
We're an EEP customer.