Skip to content
GitLab
Next

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.

Intended users

  • Enterprise that uses forking workflow with GitLab (GitLab.com and on-premise)
  • Open source
 users (Including GitLab contributors)

In the future we will also solve this issue for non-local repos

Latest Proposal

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/head or refs/merge) are available in the parent project already.
Proposal-v0.1 ### Proposal

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:

Description

  1. 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.
  2. 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.

Project membership is required, in order to use parent resources.

UX Proposal

  • Add "Allow forked projects to create pipelines" section to CI/CD > General pipelines screenshot
  • Default checkbox to unselected

Allow_forked

Permissions and Security

Because project membership is required, there is no back-door to gaining unauthorized access through this approach.

Documentation

TBD

Testing

TBD

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

Interested Customers (internal only)

TODOs:

backend

  • Create a new project-level config "Allow fork pipelines to run in parent".
  • Check pipeline triggerer's permission when the system collects variables.
  • Check pipeline triggerer's permission when the system creates deployments/evnrionemtns.
  • Allow fork MR pipelines to be created in the parent project.
  • Disallow Project/Group-level runners to pick jobs if the pipeline triggerer doesn't have access to it.
  • Remove a feature flag and update documentation (e.g. Important notes about merge requests from forked projects

frontend

  • Create a new project-level config "Allow fork pipelines to run in parent"

Feature Flag

This feature is behind the feature flag allow_fork_pipelines_to_run_in_parent (with project scope).

Slack

#f_continuous_delivery

Edited by Dimitrie Hoekstra