Group merge requests MVC (Super Merge)
Closed and Work Has Been Moved
This issue has been closed in favor of &882 because the scope of this issue is much too broad to be addressed in a single iteration. The epic linked tracks the various different problems that this issue was trying to solve as sub-epics.
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.
Further details
Nearly all products are composed of multiple components that are spread across multiple projects/repositories. For example gitlab-ce
relies on gitaly
, gitlab-workhorse
and 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.
Proposal
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
Technical considerations
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.
Links / References
https://docs.gitlab.com/ee/ci/multi_project_pipelines.html
Customers
- https://gitlab.my.salesforce.com/00161000002xBfL
- https://gitlab.my.salesforce.com/0016100000fDO7w
- https://gitlab.my.salesforce.com/00161000004bZPD
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.