[New Auto Merge Strategy] Merge Train

What does this MR do?

• CE: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/29485
• EE: Here

This MR adds one of the Auto Merge strategy - Merge Train. The specification is described in https://gitlab.com/gitlab-org/gitlab-ee/issues/9186.

This is only backend work, separated from frontend MRs.

Approach

Auto Merge Strategies:

1. Merge When Pipeline Succeeds
2. Merge Train
3. Add To Merge Train When Pipeline Succeeds

• #execute ... Activate Auto Merge on the merge request
• #process ... Event Reciever. Evaluate the current status and process accordingly. Something happened in the merge request.
• #cancel ... Cancel Auto Merge on the merge request

Event Receiver:

• When a pipeline succeeds in a merge request
• When Auto Merge enabled on a merge request (Common)
• When a merge request is dropped from a merge train, then notify to the next merge request on the train (MergeTrain Specific)

Train: | MR1 | MR2 | MR3 | ... |
Train: | MR1 X => Dropped | MR2 (wants to be notified) | MR3 | ... |
Train: | MR1 | MR2 X => Dropped | MR3 (wants to be notified) | ... |

When Auto Merge will be canceled:

• When user wants to cancel
• When merge request is closed
• When source branch is updated
• When target branch is changed => When merge request is updated, Auto Merge should be canceled

Bugs:

• Enqueue MR1 => Enqueue MR2 => Cancel MR1 (User) => What's going to happen on MR2
• Change branch should cancel Auto Merge
• current_user does not point to the right user
• Pipeline Creation

Manual QA

• Test Merge Train strategy
  • Enqueue MR1 => Finish MR1 pipeline
  • Enqueue MR1 => Enqueue MR2 => MR1 pipeline succeeded => MR1 merged => MR2 pipeline created => MR2 pipeline succeeded => MR2 merged
  • Enqueue MR1 => Push new commit
  • Enqueue MR1 => Disable option
  • Enqueue MR1 => Pipeline failed/canceled
  • Enqueue MR1 => Enqueue MR2 => MR1 pipeline failed => MR1 dropped => MR2 pipeline created => MR2 pipeline succeeded => MR2 merged

--

• push to merge request (seems to be already mentioned), => Will be canceled
• change of merge request between WIP and non-WIP, => The system fails to merge thus the merge request is dropped from merge train
• change of target branch, => The system (likely) fails to merge thus the merge request is dropped from merge train
• close and re-open of MR, => The system fails to merge thus the merge request is dropped from merge train
• removal/destroy of MR => A corresponding merge train will be deleted cascadingly thus it's same behavior with dropping a merge request from a train.

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• [-] Documentation created/updated or follow-up review issue created
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Performance and testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team