Skip to content
GitLab
Next
    • Why GitLab
    • Pricing
    • Contact Sales
    • Explore
  • Why GitLab
  • Pricing
  • Contact Sales
  • Explore
  • Sign in
  • Get free trial
  • GitLab.orgGitLab.org
  • GitLab FOSSGitLab FOSS
  • Issues
  • #14567

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.

Proposal

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.

confidentialmr

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


Original issue description

We have confidential issues now: https://gitlab.com/gitlab-org/gitlab-ce/issues/3678

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. Update, 2019-01-17: This is obviously no longer an option.

Tangentially related: https://gitlab.com/gitlab-org/gitlab-ce/issues/14566

cc @sytses @JobV @dzaporozhets

Edited Jan 23, 2019 by Douwe Maan
Assignee
Assign to
Time tracking