Federate GitLab instances for merge requests
Proposal
Bear with me, please. This, if of interest, would need more thinking and walking through of scenarios. Before even attempting to go into any sort of detail though, I wanted to gauge the level of interest for this idea.
Goal
Federate GitLab instances so a person can have an account on GitLab.public and submit a merge request to GitLab.project without needing to set up a repository / fork on GitLab.project but can keep it on GitLab.public.
Rationale
When an organisation runs its own GitLab instance, it may wish to restrict who can host repositories on that GitLab instance. The number of repositories can be restricted already, but it would take quite a bit of effort to monitor those projects to ensure they are related to the main project as it may not be in the interest of the entity running that site to become host to all sorts of projects that community members wish to set up and host. This is a data privacy and terms of use issue.
Therefore, it would be awesome if it were possible to federate GitLab instances to allow people to set up a repository on their preferred GitLab instance, either by forking a mirrored repo or setting it up from scratch and then submitting a merge request to the project's GitLab instance. That way, they would be able to keep all their repos in one place yet still access GitLab.project and submit their changes without having repositories in multiple places or being restricted in what they can or can't do on GitLab.project.
On the other hand, the entity running GitLab.project has better control over who can set up repositories on the site without restricting community contributions when they wish to run their own instance of GitLab rather than using GitLab.public, for a number of reasons, e.g. own privacy and terms of use conditions, data sovereignty considerations, branding, integrations to other systems etc.
I was inspired by the Fediverse and ActivityPub that allows people on different instances of Mastodon and other applications to consume their feeds in one application.
Things to consider
There would be a lot of things to consider as GitLab is very complex. My initial idea was born from a lightweight use of GitLab and thus by far doesn't yet consider the implications for a heavy use of GitLab. Hence why the proposal is restricted to merge requests right now rather than attempting to replicate the entire structure of GitLab in a federated way or even assign tasks to someone on another instance even though that might be fun to consider how far the idea could be taken.
Base idea
- A GitLab account holder can specify in their preferences, which GitLab repositories hosted elsewhere they'd like to be able to send merge requests to, e.g. Foo at GitLab.project and Bar at GitLab.company. For an MVP, these would need to be public repositories. Later on, maybe an access token would be needed to access private ones, which would require a whole authentication process.
- When they create a branch in their own GitLab, e.g. GitLab.public, they can specify that as merge request and can pick from any of their repositories on GitLab.public as usual and would also see the branches from the GitLab.project Foo repo and GitLab.company Bar repo that they specified earlier.
- When they pick a branch from a federated / remote GitLab repository, e.g. on GitLab.project, they could additionally specify the issue number from the other repo so the merge request can be linked to the correct issue.
- They send their merge request off and it lands in GitLab.project.
- Comments made on the merge request would be sent as notifications to their GitLab.public account and they can reply.
⚠ This is where it gets fuzzy on how this could be achieved without also having an account on GitLab.project.