Allow parent project's developers to create pipelines for merge requests for fork MRs
Problem to solve
As an open source project maintainer, I want to be able to allow a specific fork MR to create a pipeline in the parent project. For security reasons, I don't want to allow all fork MRs as I have secrets that I want to protect. I want to be able to review the changes, check if they don't try to leak the secrets, and only then allow it to run in the parent project.
Intended users
User experience goal
Only project members in the parent project can create pipelines in the parent, thus they can create pipelines from the fork-MR" (See more https://gitlab.com/gitlab-org/gitlab-ee/issues/11934#note_184868345 or https://gitlab.com/gitlab-org/gitlab-ce/issues/23902#note_123120541). The good thing of this approach is that the code has already been reviewed by maintainer/reviewers so that parent project members would notice malicious code (e.g. trying to steal secret variables, etc) before they create a pipeline for fork-MR. The downside is that it's manual process. External contributors have to ask project members to run pipelines in the parent project.
Proposal
Allow parent project's members with Role Developer and up to create pipelines for merge requests for fork MRs.
Note Since a member of the paren't project is running the pipeline he/she has access to all the project's resources. This does add a manual step for the member to perform a code review but also, adds the opportunity to review and make sure no malicious code is merged (for example stealing secrets)
For this first iteration - we will show a security warning
note: The following mocks are final except the copy which is being discussed at #217451 (comment 375870832)
| Mockup of merge request pipeline section if the user has enough permissions (Figma document) |
|---|
 |
| Mockup of merge request pipeline section if the user does not have enough permissions (Figma document) |
|---|
 |
| Mockup of modal shown when triggering a pipeline that runs forked project code on the parent ref (Figma document) |
|---|
 |
Note: The following warning needs to be rewritten. This is currently discussed at #217451 (comment 377198552)
| Screenshot |
|---|
 |
Not in the scope of this issue:
If the fork belongs to a project member, the pipeline will be created automatically.
Further details
Value being generated by this
Running full pipelines
Use case from #11934 (comment 184868345):
We're an open source project that's hosted on gitlab, and we hugely struggle with MR from forks.
For our project, running our full CI will need access to secrets, or if it doesn't automatically (effectively) giving a MR opened from a fork full access to our Kubernetes cluster etc is undesirable.
A good solution for our workflow would be to allow approvers to manually create a pipeline that runs the full normal CI on the submitted merge, which they can do after they've reviewed the changes to avoid MRs that contain nefarious code running on the cluster.
This kind of workflow is actually almost possible on gitlab today by having the approver manually push the changes to the main repo; the real downside of that workflow is that currently there's I believe no way to edit a merge request to change the source branch from the original fork to the new branch in the upstream so we have to open a second MR and lose all the context and insight in the original MR.
Running merge trains, allows for dogfooding
If merge train is enabled, currently users see a warning message in a fork MR widget that they cannot use merge train because the pipeline runs on a fork project. With this issue, the problem can effectively be resolved. This brings significant values to us that basically allows us to dogfooding merge train on gitlab-org/gitlab project. You can see more context in gitlab-org/quality/team-tasks#195.
Permissions and Security
Any project member with developer Role and up should be able to run the parent pipeline