Group-level merge requests (Super Merge)
Many organizations want a way to do development and code review across multiple repositories. For example, at GitLab we have gitlab-ce, gitlab-ee, gitlab-workhorse, gitlab-shell and gitaly that need to interoperate with each other. It is possible to manage this manually by versioning each component and tracking which versions are compatible with each other. For large organizations this is impractical and requires more effort compared to the non-Git tools they are migrating away from.
One approach is to make sure that the HEAD of all the projects always integrate, but this requires a way of changing multiple projects at the same time.
This means that you can make sure all HEAD integrates with each other right now, but it is important to know which historic commits integrated with which other commits. This is important if a bug or security issue is found so that it is possible to stop through historic states to find it was bug was introduced.
Add the ability to configure a super project
The super project will be the project which links the other projects together.
- Add new project setting 'Super project'
- Add option to add/remove projects from the super project
- A project can only be part of one super project
- A super project cannot be part of another super project
The super project should be visually distinguished from regular projects when browsing a project list
Add the ability to merge across projects
When opening a merge request to a project that is part of a 'super project' the user will be prompted to open a corresponding 'super merge request' to the 'super project'
- Merge requests to sub-projects are merged by merging the 'super merge request'
- Code review happens on the normal merge request
Add the ability to tag and branch across projects
When a branch or tag is created on the super project, corresponding branches and tags are created on the sub-projects.
The preferred method of implementation is to use submodules to track the state of each of the sub-projects. Submodules allow us to use Git to track the state of projects and how they relate to each other. Importantly, one of the objectives is to be able to verify the integration of all the related projects. This should be done using a CI job, and the GitLab CI configuration needs to be stored in a repository. If we use a Git repo for tracking state we can also use it for storing the CI configuration.
Note, the submodule file would be managed by GitLab (updated on every push/merge) and would not be writable by users by default.
- So we need a way to manage a "request" to merge code across multiple projects.
- So we want a wrapper object that is essentially multiple merge requests across multiple projects.
- We would call this a "group-level merge request".
- When you create the merge request, you select multiple projects inside a group.
- For each project in that group, you select a source branch and a target branch.
- You do code review on the group-level merge request itself.
- When you merge the group-level merge request, you merge all the constituent project merge requests itself.
- Reuse existing GitLab functionality as much as possible.
- Design the feature so you essentially just have a wrapper for multiple project merge requests.
- When the user clicks merge, behind the scenes, it is just merging all the constituent project merge requests.
- If any of the behind-the-scenes project merge requests fail, the entire group-level merge request fails. It is transactional. So behind the scenes, if one of the merge requests are merged, it is rolled back.
- The behind-the-scenes individual project merge requests are not visible to the user.