Merge trains can fail due to pipeline running in a refreshed merge ref
Description taken from https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14495:
While we were QAing on staging server, we found that there is a race condition on merge trains with https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/29569 change.
Given MR1 and MR2 are just pushed to the merge train, it will be processed as
- MR1 generates
refs/merge-requests/1/merge
and create a pipeline viaMergeTrains::CreatePipelineService
(i.e.MergeRequests::MergeToRefService
) - Pipeline on MR1 finished. MR1 is merged into master.
- MR2 generates
refs/merge-requests/2/merge
and create a pipeline viaMergeTrains::CreatePipelineService
(i.e.MergeRequests::MergeToRefService
) - Since MR2's merge status will be reset.
MergeRequest::MergeabilityCheckService
will regenerate merge ref torefs/merge-requests/2/merge
. This SHA is different from the above SHA which was used for thepipeline.sha
. - Pipeline fails because it cannot find the SHA in the ref.
To combat this problem, Merge Train should generate a merge commit at refs/merge
. This is already on our roadmap https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14296, but since we cannot wait until it has been deployed to prd, we're just implementing a part of the functionality earlier as patch.
After this fix, the above flow will be:
- MR1 generates
refs/merge-requests/1/train
and create a pipeline viaMergeTrains::CreatePipelineService
(i.e.MergeRequests::MergeToRefService
) - Pipeline on MR1 finished. MR1 is merged into master.
- MR2 generates
refs/merge-requests/2/train
and create a pipeline viaMergeTrains::CreatePipelineService
(i.e.MergeRequests::MergeToRefService
) - Since MR2's merge status will be reset.
MergeRequest::MergeabilityCheckService
will regenerate merge ref torefs/merge-requests/2/merge
. This SHA is different from the above SHA which was used for thepipeline.sha
. - Pipeline fails because it cannot find the SHA in the ref.
Edited by Oswaldo Ferreira