The GitHub encrypted secrets documentation states:
Using encrypted secrets in a workflow
With the exception of
GITHUB_TOKEN
, secrets are not passed to the runner when a workflow is triggered from a forked repository.
In light of this, what is the best-practice to configure GitHub Actions CI to run tests that depend on secret API keys as part of an open source PR review workflow?
I want to run tests that use secrets when PRs are pushed to my open source project. I do not want to do this automatically for all submitted PRs but I would like to do it automatically for PRs from project members and I would like to be able to enable/trigger the CI run for 3rd-party contributions after manual review. I understand that there are security implications to this, and I am prepared mitigate the impacts of a leaked or misused secret.
I hit this problem with the following setup:
I have a public GitHub repo in its own organization (the "main repo"). I have a fork in my personal account (my "developer fork"). I am an owner of the org repo with full permissions.
My integration tests require a third-party secret API key (say FOO_API_KEY
) to perform end-to-end tests. In each repo (main, dev fork) I have set up GitHub Secrets environments with the name test_environment
. In both repos FOO_API_KEY
is set up as an Environment Secret.
The repos have the same GitHub test.yaml
workflow available. A simplified version of the workflow is:
name: Run tests
on: [push, pull_request]
jobs:
test:
name: Run tests
runs-on: ubuntu-latest
environment: test_environment
steps:
- uses: actions/checkout@v3
- name: Set up Python 3.10
uses: actions/setup-python@v4
with:
python-version: 3.10
- name: Install package and dependencies
run: pip install .[test]
- name: Run tests
env:
FOO_API_KEY: ${{ secrets.FOO_API_KEY}}
run: python -m pytest .
When this CI action is triggered by a direct push to either the main repo or my development repo, the tests run successfully. But when the CI action runs in the main repo as part of a PR (from myself), the tests fail due to a missing FOO_API_KEY
(as expected, based on the GitHub doc cited above).
I got to this point by inspecting the CI logs and noticing that in a successful CI run, the CI logs for "Set up job" include the line:
Secret source: Actions
Whereas in a failing run, triggered by a PR, the CI logs for "Set up job" include the line:
Secret source: None
This situation is unsatisfactory, because I can not even run CI on my own PRs in the main repo without them failing due to unavailable secrets.