Product Discovery: Rebase, retest, then merge

Description

Teams need to keep master "green". It's a huge pain when someone merges a MR that breaks master because they didn't know of some conflict because their MR's pipelines was all green. It's great that master has its own pipeline with tests so it won't accidentally deploy a broken codebase, but it sucks that master is left broken, and any MR based on master will now fail as well. One strategy is to never let master break in the first place. There are several ways to do that, with various tradeoffs. This proposal is about waiting until someone presses merge to retest everything on the post-merge codebase before actually committing the merge. If the post-merge pipeline fails, abort the merge.

Proposal

When a MR is ready to be merged, allow an option that would:

Rebase or merge locally
Re-run CI
Push merged code

Obviously if CI fails, the merge will abort. If after CI, the target branch has evolved, also abort.

The advantage of this proposal over others is that it is more efficient in that it only runs the post-merge CI after review of the MR has finished. The downside is that if a conflict is introduced, you won't know until the end. Also, if another merge happens during the re-run of CI, the merge will fail and have to be started again. A full release train is one way to evolve this.

Links / references

Marge-bot: https://smarketshq.com/marge-bot-for-gitlab-keeps-master-always-green-6070e9d248df

Release Train: &101 (closed)

Solution

We will basically implement https://gitlab.com/gitlab-org/gitlab-ee/issues/895 but with some small adjustments and design updates.

Because the automatic merge and rebase retry we need to think of some abort flows and how to get that communicated to the user 😉.

Abort when source branch advanced (will auto retry)
- Abort when source branch advanced too many times 5 times (will not auto retry)
Abort when the pipeline fails (will not auto retry)
Abort manually (will not auto retry)
Prevent merge when too many concurrent merge requests competing to merge

Adjusted https://gitlab.com/gitlab-org/gitlab-ee/issues/895

For the two merge request methods (merge commit with semi-linear history and fast-forward merge), offer the ability to rebase and merge in a single action.

Note: For below, ~~strikethrough~~ indicates existing functionality that will be removed and bold indicates new functionality.

No pipeline exists (No GitLab CI set up)

MR needs a rebase
- MR is non-rebaseable
  - ~~Merge button, and an error after clicking the button~~
  - Access to source branch: Rebase locally button that shows instructions If rebase succeeds, show message “Ready to be merged automatically. Ask someone with write access to this repository to merge this request.”
    - widget
    - instructions modal
  - No access to source branch: No buttons, only message to ask MR author to rebase locally
    - widget
- MR is rebaseable
  - Access to only source branch: Rebase button. If rebase succeeds, show message “Ready to be merged automatically. Ask someone with write access to this repository to merge this request.”
    - widget
  - Access to source AND target branch: Merge and Rebase only buttons. Merge will auto-rebase+merge immediately. If Rebase only, after it succeeds, show Merge button.
    - widget
  - No access to source branch: No buttons, only message to ask MR author to rebase
    - widget
MR does not need a rebase
- Merge button

Pipeline running

MR needs a rebase
- MR is non-rebaseable
  - ~~Merge button, and an error after clicking the button~~
  - Access to source branch: Rebase locally button that shows instructions If rebase succeeds, show message “Ready to be merged automatically. Ask someone with write access to this repository to merge this request.”
    - widget
    - instructions modal
  - No access to source branch: No buttons, only message to ask MR author to rebase locally
    - widget
- MR is rebaseable
  - Access to only source branch: Rebase button. If rebase succeeds, show message “Ready to be merged automatically. Ask someone with write access to this repository to merge this request.”
    - widget
  - Access to source AND target branch: Merge (blue button) and Rebase only buttons. Merge will auto-rebase+merge immediately. If Rebase only, after it succeeds, show Merge (blue) and Merge when pipeline succeeds (orange) buttons.
    - widget
  - No access to source branch: No buttons, only message to ask MR author to rebase
    - widget
MR does not need a rebase
- Merge when pipeline succeeds button (blue)
- Merge button (orange) to merge immediately

Pipeline passed

Same as No pipeline exists, above

Pipeline failed

Will not auto retry
Loses position in concurrent merge requests list trying to merge

Merge possible but too many concurrent merge requests

widget

When rebase happens after pressing Rebase button or merge button that also does the rebasing

widget
If target branch advanced while in the process of rebasing again (Auto retries)
- widget
- When auto-retrying the rebase and spinning up a new pipeline the merge request should retain its position in the max 5 concurrent merge requests that are competing/racing to be merged

After rebase is done, and merge will happen as soon as Pipeline succeeds

widget
If target branch advanced while in the process of waiting to merge again (Auto retries)
- widget
- When auto-retrying the rebase and spinning up a new pipeline the merge request should retain its position in the max 5 concurrent merge requests that are competing/racing to be merged

Proposal with images