### 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](https://docs.gitlab.com/ee/ci/merge_request_pipelines/#important-notes-about-merge-requests-from-forked-projects) 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 * 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](https://docs.gitlab.com/ee/ci/merge_request_pipelines/)/[pull requests](https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/index.html#pipelines-for-external-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](https://docs.gitlab.com/ee/ci/variables/) 2. [Clusters](https://docs.gitlab.com/ee/user/project/clusters/) 3. [Project/group-level specific runners](https://docs.gitlab.com/ee/ci/runners/#shared-specific-and-group-runners), 4. [Environments/Deployments](https://docs.gitlab.com/ce/ci/environments.html), 5. [Service Integrations](https://docs.gitlab.com/ee/user/project/integrations/project_services.html), 6. [Release](https://docs.gitlab.com/ee/user/project/releases/) 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 https://gitlab.com/gitlab-org/gitlab/issues/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. <details> <summary>Proposal-v0.1</summary> ### 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. 1. 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. </details> 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](/uploads/05f36156dd6359a304c21dba2b89163b/CICD_settings.png) - Default checkbox to unselected  ### 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? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### 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](https://circleci.com/docs/2.0/oss/) * [Travis' use of forked projects](https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions) #### Interested Customers (internal only) * https://gitlab.my.salesforce.com/00161000005cxCt * https://gitlab.zendesk.com/agent/tickets/115341 * https://gitlab.my.salesforce.com/0016100001NkpKR * https://gitlab.my.salesforce.com/0016100001ZzcXy * https://gitlab.my.salesforce.com/0016100000dG6oO * https://gitlab.my.salesforce.com/0066100000MeW4f * https://gitlab.my.salesforce.com/0016100000sPtrS ## 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](https://gitlab.com/help/ci/merge_request_pipelines/index.md#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](https://gitlab.slack.com/app_redirect?channel=f_continuous_delivery)