Allow fork pipelines to run in parent project
Problem to solve
Currently, for merge requests coming from a forked project, no pipeline is created in the parent project. This is mostly around security concerns for those pipelines. It would expose the parent projects runner, CI variables and other items to the forked project - which is likely not desired by many.
However, there are many valid use cases where this should be allowed to happen. For instance, take an enterprise that uses a forking instead of a branching git workflow. We should provide a way to run a pipeline in this way, with the appropriate security considerations accounted for.
- Enterprise that uses forking workflow with GitLab
In the future we will also solve this issue for non-local repos
How it works now?
Currently when we do
git push we create a pipeline for a branch.
When we create a merge request we look for a pipelines created
for that branch in that source project.
The CI builds are always executed in context of source project (i.e., the fork itself). The fork needs to have it's own runners that would be executing these builds, and may not have access to appropriate secrets or other configuration needed to run the pipeline.
Forked projects cannot create pipelines in the parent project by default.
In parent project, there is a project-level config (Settings > CI/CD > General pipelines) called "Allow MRs/PRs from forked projects to create pipelines in parent". which is off by default. If this option is enabled, pipelines for merge requests/pull requests are created in parent project instead of forked projects.
With the option enabled, forked projects can 1. Create/Read/Update pipelines 2. Read container registry, by default.
With the option enabled, forked projects cannot access 1. Project/group-level secret variables 2. Clusters 3. Project/group-level specific runners, 4. Environments/Deployments, 5. Service Integrations, by default.
This rule is applied in both Public/Private fork workflow.
In a future release we will handle: the parent project can allow forked projects to access these resources by enabling additional checkboxes. NOTE:
- In PR workflow, we'd need service account in order to identify users/permissions. => More discussion in #5667
- In private-fork workflow, the parent project's runners do not need to have an ability to read repository from private-fork, because merge request refs (
refs/merge) are available in the parent project already.
By taking advantage of the "Run Pipeline for MR" button at https://gitlab.com/gitlab-org/gitlab-ce/issues/65940, we can introduce a way for members of the main (non-forked) project to run a pipeline for a fork. The way this would work is:
- The button would only be available to members of the non-forked project. This could be inconvenient in some cases, but is the only way to ensure a project member is able to review the MR and ensure there are no malicious contents.
- Upon clicking the button, a pipeline would run in the context of the MR containing the forked pipeline ref. The pipeline runs as the user who clicked on the button, with their permissions and access. This ensures the pipeline has the access it needs.
For users of the feature, there are two main ways of working to choose from here:
- Authors of the fork can be made a member of the source project, allowing them to run pipelines themselves.
- For arbitrary/untrusted forks, the author should reach out to a project member to run the pipeline.
Permissions and Security
Because project membership is required, there is no back-door to gaining unauthorized access through this approach.
What does success look like, and how can we measure that?
What is the type of buyer?
This would be driven by organizational development practices, most likely set by a Director of Engineering or above.
Links / references
- See &957 for additional UX items around
only: merge requests
- Circle CI's use of forked projects
- Travis' use of forked projects
Interested Customers (internal only)