Don't invalidate pipeline after retargetting merge request
As part of Run pipelines as any user and access GraphQL Api (#465862 - closed), https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/4113 implemented a change to the pipeline processing when a MR gets retargetted.
The relevant code is https://gitlab.com/gitlab-org/gitlab/-/blob/74f346db17b624e70184c520bfda6cc05b55a2ae/app/services/merge_requests/update_service.rb#L214-224
# `target_branch_was_deleted` is set to true when MR gets re-targeted due to
# deleted target branch. In this case we don't want to create a new pipeline
# on behalf of MR author.
# We nullify head_pipeline_id to force that a new pipeline is explicitly
# created in order to pass mergeability checks.
if target_branch_was_deleted
merge_request.head_pipeline_id = nil
merge_request.retargeted = true
else
refresh_pipelines_on_merge_requests(merge_request, allow_duplicate: true)
end
So, if the target branch gets deleted and the MR retargets, the pipeline from the MR is nullified which causes the merge checks to fail if a successful pipeline is required for merge.
In https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/4113#note_1943944597, there was a note about this also invalidating branch pipelines which was resolved as something that could be discussed outside of the security fix. I don't see any conversation having happened about that, so I'm opening this issue for that.
I would also like to expand the scope of that to also not invalidating merge request pipelines (not merged result pipelines, I can see the value in invalidating them).
Problem
Both branch pipelines and merge request pipelines will trigger on the exact same code as the invalidated pipeline, so it doesn't make sense to invalidate them in the first place. Doing so results in worse efficiency and more costs when dealing with MR chains/stacked MRs.
Proposal
Only invalidate the pipeline on the MR, if it is a merged result pipeline.