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

When new behavior is enabled (default)

  • don't apply the default only: [branch, tag] from Entry::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 run MergeRequests::CreatePipelineService. Having removed only: [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

When new behavior is disabled

Same as today:

  • Entry::Processable has only: [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

Make changes to the default configuration of CI to avoid creating redundant second pipelines.

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 defines rules: 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)
Edited by 🤖 GitLab Bot 🤖