Actions: Securely run test workflows on forks (PROTOTYPE - do not merge) #1334
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #enter-issue-number
N/A
What changes did you make and why did you make them?
Previously, the build-and-test workflow was triggered by the
pull_request
event trigger, but this does not grant secrets access to forks, which is necessary to run unit tests. The inverse is true forpull_request_target
, except that it's ineffective and misleading, as it tests our develop branch without an explicit code ref checkout. Explicit checkouts with pull_request_target are strongly discouraged and goes against it's use-cases.Given the security steps we've already taken, including the approval step and testing secrets auditing, we decided to keep the workflow and grant access to secrets on forks. For increased security, I implemented an auto-labeler to automatically label any forked PRs making changes to sensitive files (such as scripts, package.json, workflows, etc) to circumvent human error. This PR fixes our build and test workflows for forks, effectively prevents prebuild jobs without proper permissions, and adds a layer of protection against human error in PR reviews.
To-Do:
workflow_run
Actions Changelog:
labeler.yml
: config for the labeler workflow, determines sensitive files.community-label-forked-prs
: labels forked pull requests with 'needs-file-review` if sensitive files detected.build-and-test-prs
: updated to exit if the triggering PR is a fork, to avoid the dependency installs on forks.build-and-test-forks
runs workflow on forks only, exiting before build if sensitive file label is detected. This can be manually removed by staff after reviewing the files.Resources:
Did you run tests? Share screenshot of results:
How did you find us? (GitHub, Google search, social media, etc.):