Expose additional CI_ variables to a branch pipeline that runs after an MR is merged
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Problem to solve
We configure master such that nobody can push directly to it, all changes must go through an MR. So in our pipeline we want to define jobs with only: master and have the pipeline that is run after an MR is merged perform so actions specific to that MR. For example lets say I have a Packer build for AWS AMIs. In the MR pipeline I deploy an instance of the AMI and run integration tests. When the MR is merged to master I want to promote the AMI to released status without rebuilding it. So when I build the AMI I tag it with the commit hash, and then in the master branch job (ie the one that runs after the MR is accepted) I need to know the commit hash to look for. While the MR is open, I have a CI_MR env variable for that. But after the MR is merged, I have to run git shell commands to parse out the parents of the commit I'm building, and infer that the commit I want is the parent that is not CI_COMMIT_BEFORE_SHA.
Intended users
Developers, DevOps Engineers, Release Managers
Further details
Proposal
Expose CI_ variables regarding the source branch in a pipeline that is run as the result of an MR being merged. An incremental implementation could be the first release exposes such variables (perhaps CI_COMMIT_PARENT_# and CI_COMMIT_PARENT_#_REF_SLUG) when the commit being checked out and built happens to be a merge commit, and then later release includes additional context about the MR.
Permissions and Security
I don't think any permission changes are needed.
Documentation
https://docs.gitlab.com/ee/ci/variables/predefined_variables.html https://docs.gitlab.com/ee/ci/merge_request_pipelines/
Testing
IT should be fully backwards compatible. However if CI_MR_* variables are added to jobs that don't have only: merge_requests or have jobs run on both merge_requests and branches then people who use those variables in their script to distinguish could see unexpected behavior.
What does success look like, and how can we measure that?
In the .gitlab-ci.yaml linked below I can replace the git show command output parsing with predefined variables.
Links / references
https://gitlab.com/jghal/ci-post-merge-variables/blob/master/.gitlab-ci.yml