Avoid duplicate pipelines in merge requests when job scheduled for both branch and merge request pipelines
Problem to solve
When running merge request pipelines, pushes to a MR create two pipelines: a "branch" one, and a a "merge request" one. This may be redundant and there should be a way to prevent it, that doesn't involving always disabling one of them (e.g. disabling all branch pipelines) or a specific action from the pusher (e.g. using the ci.skip option).
Intended users
Further details
This was already suggested in gitlab-foss#56632 (closed), which was marked as a duplicate of #29654 (closed). But it is obvious the latter doesn't address this issue, as discussed from #29654 (comment 281772280).
The particular use case is:
Branch pipelines run job A, MR pipelines run jobs A + B.
Normal pushes to a branch should create a branch pipeline (job A)
Creating a MR should create a MR pipeline (jobs A + B)
Pushing to a branch for which a MR is open should create only a MR pipeline, since a branch pipeline would be redundant.
The advantage would be saved runner time (specific or shared), faster results (especially with limited runners), cleaner pipelines.
Proposal
It seems branch and MR pipelines are created independently and there's no way to know the details of one from the other. In particular, variables like CI_MERGE_REQUEST_TARGET_BRANCH_NAME only exist in the "piece of code" that checks for MR pipeline creation, and the "piece of code" that checks for branch pipeline creation does know nothing about it.
I would suggest either:
-
Create the pipelines only in the order MR, branch, and have a way (in CI config,
workflow/rules) to check whether a MR pipeline for this same commit already exists. -
Add a way (again, in CI config,
workflow/rules) to check if there is an open MR for this branch.