Confidential merge requests
Description including problem, use cases, benefits, and/or goals
Not all code can be made public immediately. For instance, for security patches you want to keep these out of the main codebase until they are resolved completely.
Currently you have to maintain a separate private mirror to work on this. Which is not very convenient. An option to have confidential merge requests would make it easier to handle such cases.
The ability to create a confidential MR. A confidential MR is like a confidential issue: only visible to project members. Because the code has to be private as well, we'll utilize a private fork to hide the code. The code would automatically be accessible by all current project members.
This would work by having a button to
Create a private MR. This button would:
- create a confidential MR with a new branch that lives in a private fork
- show the links to push to/ fetch from this branch in the confidential MR
- the private fork automatically gives access to you and the members of the project you're creating a MR to
- the private fork shows to the user visiting it that it's a private fork created for a confidential MR, with a link to
Links / references
We have confidential issues now: #3678 (closed)
Should we also have confidential merge requests, so patches to confidential issues can be developed in private? We currently do this on dev.gitlab.org.
Of course the branch and its commits would still be public, but chances are relatively small people will read every commit and branch, and commits can be carefully named to be technically accurate but not give away that it fixes a vulnerability.
Tangentially related: #14566 (closed)