Support Integration-Manager workflow in GitLab for private team repositories
The Integration-Manager workflow is documented here - https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#Integration-Manager-Workflow.
The workflow basically looks like this.
- There is a team/group account under which there are members in various roles like developers, admins and etc.
- The main repository of the project is hosted under the team namespace and everyone in the team/group has read-access to it. The admins have write access to it.
- The developers in the team who want to work on the codebase, fork it under the team namespace and not their individual namespace so that the fork is readable by all the group members. Only the developer has write access to it.
- Developer works on some changes and creates a merge request.
- Reviewers/admins review the changes in the pull request by adding the developer's fork as a remote, pulling the change locally and testing it.
- If the changes are okay, they are merged.
Since GitLab the permissions and roles in GitLab are tightly coupled and pre-defined, the developer user cannot create a fork under the team namespace. This means that the group members do not have read access to the fork. So they can only see the changes in the merge request web UI and cannot add the developer's fork as a remote and pull changes either to review or merge. The workaround could be to make the developer provide read access to all the group members after creating the fork. But with a large team, this becomes cumbersome.
Note that the above workflow works out of the box on Bitbucket and GitLab for private repositories. This issue is for supporting the Integration-Manager workflow for private repositories on GitLab.
This workflow works perfectly fine when the main repository and its fork are public but not when dealing with private repositories