CODEWITHSUNDEEP
github-actions
Ross Bencina
Ross Bencina

Reputation: 4193

How to use GitHub Actions Environment Secrets in open source pull request CI workflow?

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.

Upvotes: 8

Views: 1227

Answers (1)

Marwen
Marwen

Reputation: 41

Using the pull_request_target event instead of pull_request in your GitHub Actions workflow is a suitable approach for this scenario.

It allows workflows to access repository secrets when triggered by pull requests from forks, addressing the limitation you've encountered. However, it's crucial to handle this feature with care due to its security implications.

Upvotes: 4

Related Questions