Skip to content
/ ok-to-test Public template
forked from imjohnbo/ok-to-test

Example workflow configuration showing how to use GitHub Actions secrets in pull requests from forks πŸ΄πŸ”‘

License

Notifications You must be signed in to change notification settings

jagoodhand/ok-to-test

Β 
Β 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 

History

24 Commits
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

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:

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:

  1. 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.
  2. Which workflow(s) need secrets. In this example, it's Integration tests, and I would need to fill in my tests here.
  3. 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

  1. A fork pull request is opened.
  2. A unit test workflow runs. Secrets are not available to this workflow.
  3. 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. ⚠️
  4. They comment /ok-to-test sha=<head-sha> on the pull request.
  5. A repository_dispatch API request is sent to this repository. See guidance below on how to authenticate.
  6. 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! πŸ’«
  7. 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:

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

Contributing

Pull requests are welcome!

License

MIT

About

Example workflow configuration showing how to use GitHub Actions secrets in pull requests from forks πŸ΄πŸ”‘

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published