Ok To Test

Example workflow configuration showing how to use GitHub Actions secrets in pull requests from forks 🍴🔑

Summary

An Ok To Test workflow is configured so that when someone with write access to this repository comments ok-to-test sha=<head-sha> on a pull request from a fork, a "privileged" Integration tests workflow needing secrets is triggered. In parallel, a "non-privileged" Unit tests workflow not needing secrets is triggered on any pull request.

About

GitHub Actions purposely limits the secrets available to pull requests from forks for security reasons:

GITHUB_TOKEN is read-only
Other secrets aren't available at all

Though this provides peace of mind, many projects depend on the fork pull request model. If you've configured a GitHub Actions test workflow to trigger on pull requests, and those tests require secrets, the secrets aren't available and the workflow fails.

No longer with this workaround, which shows an example Prow-like /ok-to-test sha=<head-sha> slash command configuration! 🥳

This project is not affiliated with GitHub.

Setup

This is a template repository with three example workflows. Start by creating a new repository ("Use this template"). Then, consider for your use case:

Which type of token you'll use to emit the repository_dispatch event in Ok To Test. Set the secrets in your repository accordingly, e.g. I used a GitHub App and had to save secrets called APP_ID and PRIVATE_KEY. Remember: if you also choose GitHub App authentication (preferred), you must create and install it on the repo(s) in which this configuration will run.
Which workflow(s) need secrets. In this example, it's Integration tests, and I would need to fill in my tests here.
Which workflow(s) do not need secrets. In this example, it's Unit tests. These types of workflows can simply trigger on pull request.

Usage

As someone with write access, comment /ok-to-test sha=<head-sha> on an incoming pull request to set off this Rube Goldberg machine 😄. The head sha is the first seven characters of the most recent commit of the incoming pull request. For example, /ok-to-test sha=742c71a.

Example

A fork pull request is opened.
A unit test workflow runs. Secrets are not available to this workflow.
Someone with write access looks over the pull request code. ⚠️ Before proceeding, they should be sure the code isn't doing anything malicious like secret logging. ⚠️
They comment /ok-to-test sha=<head-sha> on the pull request.
A repository_dispatch API request is sent to this repository. See guidance below on how to authenticate.
An integration test workflow runs, checking out the merge commit if the head sha hasn't changed since the comment was made. Secrets are available to this workflow! 💫
The pull request status check is updated to reflect the success or failure of the integration test workflow.

Note that this sequence also works for branch based pull requests, as you'd expect!

Authentication

Choose one of these authentication methods for the repository_dispatch helper action, peter-evans/slash-command-dispatch, in ok-to-test.yml:

Personal access token with repo scope
OAuth "app" token with repo scope
⭐️ Preferred: GitHub App installation access token with contents: write and metadata: read permissions

GitHub Apps have distinct identities on GitHub – no seat taken up by a machine account, no potential for leaking your personal credentials, and no rate limit sharing!

Credits

Prow for the idea for ok-to-test
A few handy community actions, peter-evans/slash-command-dispatch, tibdex/github-app-token, and actions/github-script

Contributing

Pull requests are welcome!

License

MIT

yukirii/ok-to-test