Group merge requests MVC (Super Merge)
Problem to solve
Many teams need to make changes across multiple projects to ship a feature. Changing each component one by one is laborious and makes code reviewing such changes fragmented. When a single logical change spans multiple projects, it should be possible to code review, approve and merge the change in a single location.
Nearly all products are composed of multiple components that are spread across multiple projects/repositories. For example
gitlab-ce relies on
gitlab-shell, and changes to these components are often coordinated with changes to GitLab. Often these changes should be reviewed together as a single logical change because together they result in one functional change that impacts a user. Spreading the code review over multiple independent changes to multiple projects can make it harder to review the change in the context of it's ultimate purpose.
In addition to the code review use case, some teams treat
HEAD of the same named branch as always integratable. This is typically true of teams using centralized version control systems like Perforce and means that a change spanning multiple repositories can be merged as a single change. These tools also provide a global history so that every version of the product can easily be checkout and built. A collection of Git repositories do not have these properties because they are independent of each other.
We should provide a single interface for performing a code review for changes that span multiple projects. From the users perspective there should be only one source of truth
A developer should be able to create a group merge request with in a group
The group merge request may contain changes to projects in that group. Optionally, it may also include projects in sub-groups, and projects explicitly shared with the group (subject to complexity).
The source branch and target branch for each project should not need to be the same. It should not be assumed that related projects have identical branching strategies. Particularly, source branches may have issue numbers specific to the project they are in, or be authored by different people who have different branch naming tendencies.
A CI pipeline should be run for each project as if a merge request had been created for each project
The approval rules for each project should be enforced on the group merge request, so that creating a group merge request is the union of all requirements.
This prevents group merge request becoming a method of bypassing requirements, and avoids creating additional configuration specific to group merge requests.
Group merge requests should be shown in the group merge request.
Merging the group merge request should merge changes to all projects.
A group merge request can only be merged if all changes to all projects have been approved and meet project level merge requirements. The change is NOT merged atomically.
If one of mores components of the merge fails, the merge can be re-attempted for the failed components.
API to create group merge request, and add/remove projects
Possibly implement by creating a
group-merge-request concept that is constructed from multiple project
merge-request. Benefits of this is automatically getting approvals, CI pipelines etc
This is similar in structure to an Epic which has a description and supports labels from the group the epic is created in.
In contrast, it seems confusing to have
n+1 merge requests for a single logical change that should be reviewed and merged together. An epic is a collection of work the be delivered over a months of time, while merge requests should be small and short lived. Multiple merge requests increases the administrative burden of small related changes rather than decreasing the burden of these changes.