Merge request pipelines for forks
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 may not be desired by some.
A possible alternative would be to have a pulling mechanism, such that the forked project creates the merged ref inside of that fork and runs it there: gitlab-ce#55013.
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. Or even an open source project that, understanding the security concerns, still wishes to have pipelines run on the parent project's runners and infrastructure.
- Enterprise that uses forking workflow with GitLab
- Enterprise that uses forking workflow with GitHub and wants to use GitLab CI/CD
- Open Source projects that live on GitHub but want to use GitLab CI/CD
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 (fork). The fork needs to have it's own runners that would be executing these builds.
- Allow merge requests from external forks to create
merge-requestpipelines in the parent project.
- We would always create a pipeline for a merge request in context of target project.
- We would make these CI builds for merge request to be run using target project's runners.
- We would limit the
Secure Variablesexposed to CI builds for merge requests.
- We would fire pipeline creation when: a new merge request is open / a merge request is updated.
- Add a new checkbox under
Generalbelow "Public piplenes" called something like:
Allow forks to create merge request pipelines (?)
- Have the
?point to documentation that is specific about the security concerns around variable exposure, etc.
- For the first release in %12.4 have this be default off everywhere and for all new projects. Reassess this default behavior at 13.0
This behavior could be further limited by the parent project with
Permissions and Security
A number of considerations were raised on the original issue around the security of this feature and how it interacts with our existing security model:
- Security of variables. This will expose improperly configured variables to potential attackers, and thus any change in behavior needs to be clearly communicated to users.
- Possiblity of cache poisoning attacks. We should consider not allowing this pipelines to push to cache
Will need to make sure that the risks and benefits are
There is a risk in this feature for breaking existing forking workflows and also incorrectly exposing variables.
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)