Backend: Make the workflow to avoid duplicate pipelines in merge requests the default configuration
Problem
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).
An MVC solution is being rolled out through this issue by making changes to the docs: #299409 (closed) since making this configuration could be a potential breaking change. Proposal by @marcel.amirault #299517 (comment 491368979)
Evidences
Comments in #201845 (closed)
Proposal
new behavior
is enabled (default)
When - don't apply the default
only: [branch, tag]
fromEntry::Processable
- In
Git::BaseHooksService
we check if there are open MRs for the (source) branch.- If so, we skip creating a pipeline since
Git::BranchPushService
will run eventually runMergeRequests::CreatePipelineService
. Having removedonly: [branch, tag]
I believe a merge request pipeline should always be created - If not, create a pipeline for branch. The
Git::BranchPushService
won't update any MRs either so we'll have only 1 pipeline
- If so, we skip creating a pipeline since
new behavior
is disabled
When Same as today:
-
Entry::Processable
hasonly: [branch, tag]
defaults -
Git::BaseHooksService
attempts to create a branch pipeline -
Git::BranchPushService
attempts to create a merge request pipeline if there are open MRs for the same branch
Original (previous) Proposal
If workflow:rules
is not specified, we default it to:
workflow:
rules:
- if: $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
when: never
- when: always
This breaking change would affect only pipelines where workflow:rules
is not defined.
We need to ensure we run extensive tests when implementing this to verify the extent of the breaking change. For example:
- branch pipeline is still created when no open MRs
- merge request pipelines are created when open MRs are present
- test the above with and without merged result pipelines
- what happens when a CI config doesn't use
workflow:rules
but definesrules:
for each job?
Document this default behavior, any breaking changes and what the user should do going forward.
Behavior changes
@marcel.amirault has a very good comment explaining the pipeline consequences of this change. @fabiopitino and @drew both have comments #325780 (comment 596431419) and #325780 (comment 597226554) on that summary.
Next Steps
Based on this discussion, the next steps involve:
- Schedule a spike to assess the number of affected users
- Schedule a spike to assess the feasibility of the proposal (see this comment)