Define a new variable, similar to CI_COMMIT_SHA, that does not change in merged results pipelines
Problem to solve
As discovered in a recent test of Merge Trains in the GDK project, the CI_COMMIT_SHA
variable returns a different SHA depending on the type of pipeline. This make configuring jobs/scripts that use CI_COMMIT_SHA
more difficult than needed. The fix we came up with was: gitlab-development-kit!1548 (diffs).
What's happening is a bit difficult to explain, but the CI_COMMIT_SHA
in a merged results pipeline is not the same as in regular branch/MR pipelines. In a regular pipeline, CI_COMMIT_SHA
is the SHA of the latest commit on the branch.
In merged results pipelines, the source branch and target branch are combined into a new internal-only SHA, which is what is stored in CI_COMMIT_SHA
. If you have a script that needs the latest commit SHA, but in a merged results pipeline, you need to use CI_MERGE_REQUEST_SOURCE_BRANCH_SHA
instead.
The problem arises from Draft:
(WIP) MRs, which run in "detached" mode. This means that the CI_MERGE_REQUEST_SOURCE_BRANCH_SHA
variable doesn't exist, and you need to use CI_COMMIT_SHA
again, which is why the GDK's script looks like:
if [ -n "${CI_MERGE_REQUEST_SOURCE_BRANCH_SHA}" ]; then
checkout "${CI_MERGE_REQUEST_SOURCE_BRANCH_SHA}"
else
checkout "${CI_COMMIT_SHA}"
fi
Proposal
Add a new variable called:
CI_LATEST_COMMIT_SHA
This will always return the latest commit for the branch pipeline, no matter what type of pipeline is running, which will simplify working with Merged Results pipelines.
What does success look like, and how can we measure that?
Success will be shown by the ability to configured more MR pipeline jobs that work the same way in both Draft (detached) mode and full Merged Results mode, with a single variable and no extra logic like above.