Cross projects MR with CLI tool

Summary

According to the discussion, I want to describe the cross repos MR feature that JiHu is currently developing.

1. the target scenario is for developing AOSP-based product, which Gerrit is the current tool for best practice
2. we developed a CLI tool called mono, which is refactored based on repo tool . Gerrit uses repo tool to handle cross-repo push operations.
3. AOSP project contains hundreds of repos. Basically to develop a new feature, developers need to commit changes on multiple repos and push them via repo tool to Gerrit and create several changes (where Gerrit do code review and aproval). Similarly, we require users to push their commits via mono tool to GitLab and create several MRs, and each repository creates 1 MR for all the commits within it.

User Workflow

Scenario: Suppose the developer is developing a new feature for AOSP product, and it require changes on 3 repos named A, B and C, and each will create a MR named MR-A, MR-B, MR-C

1. the developer needs to create feature branches via mono tool locally.

## create branch in current repo 
mono start FEATURE_BRANCH_NAME .
## create branch in all repos
mono start FEATURE_BRANCH_NAME -all

2. the developer completes all the development work, and pushed all the commits to the remote server via mono tool

## pull the remote changes and checks conflicts
mono sync
## push all the local commits in all the repos to the remote server
mono upload

3. The remote server will create the corresponding MR-A, MR-B, and MR-C in each repo(project), and will unify them with the label monorepo, which are distinguished as related MRs with their branch name, and at the same time, the original merge button on the MR detail page will be hidden, and a new component with Merge All button will be added.
   • Why need label monorepo? We need to distinguish those cross-repo MRs from normal MRs, so we need to add a new field. However, JiHu-only approach cannot add extra database schema due tech limitation, so we use label as a workaround
   • Why need a new component? For JiHu-only approach, this has lower risk of forking conflicts
4. the developer chooses MR-A to view the detail, and sees the all the related MRs in the new component

scenario	design
Overview
If there is no mergeable MR，Merge All button is diabled
If all MRs are mergeable，Merge All button is enabled
Choose Merge All，merging process is started
If there is other ongoing merging cross-repo MRs (for other feature)，Merge All button is diabled
Merge completes
If a MR is closed, it will not prevents other MRs to be merged together