GitHub Actions - empty env secrets

Question

I've started playing with GitHub actions, but I'm struggling with accessing repository secrets which I pass as env's.

My workflow file:

name: Invite
on: 
 pull_request:
 branches: [master]
 types: [closed]
jobs:
 invite:
 runs-on: ubuntu-latest
 steps:
 - name: Hello world action
 uses: lekterable/inclusive-organization-action@master
 env:
 SECRET_TOKEN: ${{ secrets.SECRET_TOKEN }}
 organization: string
 SUPER_SECRET: ${{ secrets.SUPER_SECRET }}

action index file

const core = require('@actions/core')
const github = require('@actions/github')
const run = async () => {
 try {
 ...
 console.log('env', process.env)
 const token = process.env.SECRET_TOKEN
 const secret = process.env.SUPER_SECRET
 const organization = process.env.organization
 console.log('organization', organization)
 console.log('token?', !!token)
 console.log('secret?', !!secret)
 console.log('token length', token.length)
 ...
 } catch (error) {
 core.setFailed(error.message)
 }
}
run()

as you can see I'm passing 3 env's, the organization which has a value of 'string' exists as expected, but SECRET_TOKEN and SUPER_SECRET are empty.

enter image description here

And yes, I do have the secrets set in the repo which runs the action:

enter image description here

Is there something that I'm doing wrong?

• lekterable: Here for example: help.github.com/en/actions/…
• lekterable: They are talking about forking the repo in which the workflow is defined not about forking a repo of the action. In my case it would be the 'github-actions-test-repo', so if someone forked it, he would not have access to the secrets, which obviously makes sense, but I'm not working on a fork, as it's my repository. Appreciate the trying though, thanks for that ;)
• Lawrence Cherone: did you re-run npm run build to update your changes? to ./dist/index.js, ive essentially setup the same and having no issues, github.com/lcherone/gh-actions/commit/… the secret env var (process.env.foo) won't show its values but it is 10 chars long. I'm thinking now you just have old code in ./dist.
• lekterable: you were actually right when mentioning the forked repo, I just understood that they meant that when you are opening pull requests IN the forked repo, then action will not get secrets, but actually when you are opening PR FROM the forked repo to the main one, actions still won't have access to them, thanks for your help :)
• Yuri Astrakhan: I have implemented a workaround documented in stackoverflow.com/a/61450807/177275 to solve these types of problems. Essentially an action that runs on PR creates some artifacts, and later a cron job that runs every 5 minutes scans for those artifacts and acts on them. I use it to post build results to the pull request page as comments, but you can adapt the same approach for other use cases.

Answer 1

In my case I had to pass the secrets to a reusable workflow by adding secrets: inherit to the parent job

jobs:
 call-workflow-passing-data:
 uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main
 with:
 config-path: .github/labeler.yml
 secrets: inherit # <= this one

Doc: https://docs.github.com/en/actions/using-workflows/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow

• Dre: Beauty! This is exactly what I needed as well!
• djvg: Do note that secrets: inherit only works within the same organization or enterprise: "The inherit keyword can be used to pass secrets across repositories within the same organization, or across organizations within the same enterprise." Otherwise you'll still get null.

Answer 2

Update

While the original answer below does still apply to public repositories, there are a couple of new updates that may help for some use cases.

• If your repository is private, you can now enable workflows from forks.

• If your repository is public, there is a new pull_request_target event that is not subject to any token restrictions.

Original Answer

The reason you are experiencing this behaviour is because the Invite workflow is being triggered by a pull request from a forked repository.

With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository.

When this happens, the actor of the workflow is the user that opened the pull request. If that user doesn't have write access to your repository then they cannot use secrets (other than GITHUB_TOKEN).

Anyone with write access to a repository can create, read, and use secrets.

ref: https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets#using-encrypted-secrets-in-a-workflow

If you run this step in your workflow you will see that it has nothing to do with your action. The TEST_SECRET secret won't be available in the workflow either.

 - name: Test
 env:
 TEST_GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 TEST_SECRET: ${{ secrets.TEST_SECRET }}
 run: |
 echo ${#TEST_GITHUB_TOKEN}
 echo ${#TEST_SECRET}

Test secrets on pull requests from forks

Checking the event data in the GitHub context you'll see that actor is the user that forked the repository and opened the pull request.

 - name: Dump GitHub context
 env:
 GITHUB_CONTEXT: ${{ toJson(github) }}
 run: echo "$GITHUB_CONTEXT"

This is a different but related issue answered by a GitHub staff member where it's explained that these limitations on forked repositories exist to "prevent malicious actors from using actions to poison upstream or downstream repos."

• lekterable: yup, you are right, I just thought that when talking about forked repo they were speaking about workflows triggered IN the forked repo, I didn't expect that action triggered by a PR merged to the main repository was also the case. Can you think of a way of doing this? I mean I really need in an action triggered by a PR merged to the main repository to have access to the secret
• peterevans: I’ve run into the same issue but for a slightly different use case. I’ve tried a couple of ways to work around it but unfortunately not found anything that works. Even if I had found a work around I imagine that GitHub would find a way to close it off. It’s basically a privilege escalation security issue. The only way to use secrets is to have an event that is triggered by a user with write access.
• Danielo515: Can you think un any other scenario where this could happen? I'm working on my own repository and I have this exact problem
• user3770635: so, is there any workaround to resolve this issue?

Answer 3

I've found a solution, what I did to work around it is instead of running the action on closing the PR I'm running it on a new commit on master, this has to be triggered by someone with 'write rights' to the repo, therefore, it has access to the repo secrets.

It's a bit harder to check if the commit is a merge commit and we have to explicitly fetch more info about the PR, but it works. Source code of an action I was trying to build if someone is interested: https://github.com/lekterable/inclusive-organization-action