<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=300146) </details> <!--IssueSummary end--> ## 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: https://gitlab.com/gitlab-org/gitlab/-/issues/299409 since making this configuration could be a potential breaking change. Proposal by @marcel.amirault https://gitlab.com/gitlab-org/gitlab/-/issues/299517#note_491368979 ## Evidences Comments in https://gitlab.com/gitlab-org/gitlab/-/issues/201845 ## 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 <details> Make changes to the default configuration of CI to avoid creating redundant second pipelines. If `workflow:rules` is not specified, we default it to: ```yaml 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. </details> ### Behavior changes @marcel.amirault has a [very good comment](https://gitlab.com/gitlab-org/gitlab/-/issues/325780#note_596378171) explaining the pipeline consequences of this change. @fabiopitino and @drew both have comments https://gitlab.com/gitlab-org/gitlab/-/issues/325780#note_596431419 and https://gitlab.com/gitlab-org/gitlab/-/issues/325780#note_597226554 on that summary. ## Next Steps Based on [this discussion](https://gitlab.com/gitlab-org/gitlab/-/issues/300146#note_1082672514), 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](https://gitlab.com/gitlab-org/gitlab/-/issues/300146#note_994383553))