Allow deploys to happen on PRs created from forked repository

[anthony-malkoun]

Use Case

https://github.com/dpc-sdp/ripple is an open source repository. As an open source repo third parties are contributing changes back our repo that we want to test against a Lagoon environment.

Issue

Normally PRs against the repository create Lagoon environments as expected and are used for testing. We would like this to happen for PRs created from a forked repository as well. Currently a PR created from a forked repo has the following log message.

[2021-07-06 05:22:38] [info]: Handling github:pull_request:opened for project ripple 
[2021-07-06 05:22:38] [info]: lagoon-logs: Send to lagoon-logs: *[ripple]* PR 992 opened. No deploy task created, reason: Head/Base not same repo

Is this something that can be changed or enabled easily?

[rocketeerbkw]

Is this something that can be changed or enabled easily?

This is not a feature that's supported, so it can't be "turned on" easily. Lagoon needs access to the git repo to build the images and there isn't any guarantee that it will have permission to do a checkout from a repo that's not configured in the Lagoon project.

Supporting this would potentially allow any random user to create environments which directly impacts billing. Imagine checking in a 100GB file and opening 10 PRs, exhausting dev environments and disk space.

Maybe we could put this behind a flag, add some docs/warnings and accept that elevated build errors are a possibility?

[seanhamlin]

To add to @rocketeerbkw's point. Just allowing forked repo PRs as is would be a bad idea. We would need to have more guard rails in Lagoon:

• Some sort of crypto miner detection (see https://layerci.com/blog/crypto-miners-are-killing-free-ci/)
• Some sort of sensible maximum time a build is allowed to run (e.g. 30 minutes)
• Some sort of abuse detection (e.g. no more than X builds per hour per fork)
• Better request maximums on build pod requests (e.g. CPU and RAM limits)
• Security implications of running untrusted code within your project (drush @production sql-drop anyone)

There are also cost implications to be aware of.

You always can add the forked git repo as it's own Lagoon project, this has several benefits:

• provides a gate for the author to pass through (so you need to 'approve' them first)
• the non-production env limit is per fork, which helps to address abuse
• avoids the above security implications (sandbox++)
• you can also deploy them to another cluster entirely, another layer of defence against untrusted code. In AWS you can use lower cost spot instances to power the cluster, to drive the cost down

[tobybellwood]

not planning to implement anything for forked repos