Danger JS check run cannot proceed when PRs raised from forked repositories (i.e. open source contributions)

[TomStrepsil]

When PRs run from a forked repository (which is the recommended way to contribute externally), they do not have write access to the base repository or access to its secrets. This is preventing the danger check from writing comments to pull requests, which is how it reports failure.

Could not add a commit status, the GitHub token for Danger does not have access rights.

This was discovered in #21 . The failures are obfuscated, requiring the contributor to yarn danger:local to discover the issue.

This exists as an issue on the danger-js repository:

Github Action fails when PR comes from forked repo

GitHub added a new event, pull_request_target, seemingly to cater for this exact problem:

In order to protect public repositories for malicious users we run all pull request workflows raised from repository forks with a read-only token and no access to secrets. This makes common workflows like labeling or commenting on pull requests very difficult.

In order to solve this, we’ve added a new pull_request_target event, which behaves in an almost identical way to the pull_request event with the same set of filters and payload.

...however, it has serious security implications. Danger JS supports this event, but with the security implications called out, and because there's no access to the source repo filesystem, this would probably not provide the required filesystem access for the custom danger scripts web-toggle-point uses.

There's a danger-proxy project that purports to solve the "danger from a forked repo PR" issue, stating the problem:

...setting up Danger to run on a public repository can be a bit tricky to do properly. The main issue stems from ensuring that Danger has a GitHub access token to use to interact with the GitHub API while simultaneously preventing that token from being disclosed to the world.

...but this seems complicated, needing an external service to be hosted, etc.

If danger could support the idea (which is floated in an unresolved issue), the canonical/secure setup would be a split process utilising another github feature seemingly created for this problem statement, the workflow_run trigger:

Runs triggered by the workflow_run event always use the default branch for the repository, and have access to a read/write token as well as secrets. As an example, as a maintainer you could set up a workflow that takes the artifacts generated by the pull request workflow, do some analysis, and post comments back to the pull request. This event is also available as a web hook and works all repos.

This should enable danger to run in context of the forked pull request, generating an artifact, that is then retrieved by a triggered workflow running in the source repo context (and thus has full write access), which actually comments on the PR.