How can I test if secrets are available in an action?

[paulb777]

I’d like an action to run on PRs from the main repo, but not from PRs from forked repos.

[Yanjingzhu]

Secrets are not passed to workflows that are triggered by a pull request from a fork. As you said , your PRs are within the main repo. Then the secrets could be passed in workflow. 

How do you use secrets in your action? Use secret variables as action input variable value? 

 

If so, you could check your logs , the secrets variable value will be masked with *** . 

If I misunderstanding your scenario, please share your workflow yml content here.  

[paulb777]

To clarify, I’d like my CI to run all the jobs and pass when run from the main repo. When someone sends a PR from a forked repo, I’d still like the subset of jobs that don’t require secrets to run and CI still to pass. 

I’ll follow up with a detailed example in the next day or two…

[paulb777]

I was able to get it working by testing every step of the job for the existence of the environment variable associated with the secret.  See firebase/firebase-ios-sdk#5180.

It would be nicer if there were away to check for secrets availability at the job level.

[Yanjingzhu]

@paulb777 I checked your PR, you use secrets as the value of environment variables. You could set the env in job level.  Then the env could be used in your scripts directly. In bash, use it in syntax $var_name

jobs:
  build:
    env:
      key1: ${{secrets.test2}}
    runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- run: echo $key1
  if: ${{env.key1}} == 'aaa'

You could enable step debug logging, in set up job step, the secrets will be evaluated. 

set up job.png862×404 10.9 KB

[paulb777]

Thanks @yanjingzhu. Setting the secret environment variables at the job level is much cleaner.

I tried several different locations and variations for the if (see the commits in https://github.com/firebase/firebase-ios-sdk/pull/5188), but wasn’t able to find a way to use it to disable the job when the secret environment variables are not available. 

[Yanjingzhu]

You can only use the env context in the value of the with and name keys, or in a step’s if conditional.

It is not supported to use env in job’s if  conditional. 

And screrts context could not be used in if conditional, neither job’s if  nor  step’s if  .

So, it is not possible to disable a job by identifying secrets . I am afraid that you need to add if contional to each steps.  Sorry for any inconvenience. 

[dwertent]

Thank you for the detailed reply.
This is really inconvenient, is there any plan on changing this?

[itsalaidbacklife]

I would also love to see an official approach to handling this. In particular, this is something that would be highly useful for open source repositories where some updates are managed through forked clones and some through branches in the original repository. Workflows triggered by forks will not have access to secrets and so being able to neatly handle those in a different way would be a very helpful.

[ojeytonwilliams]

This might not be what you’re after, but you can disable individual steps by putting the secret into a job’s env and then using

if: ${{ env.SECRET_KEY != 0 }}
inside each step.

Setting env at the workflow level does not appear to work, so ‘if’ for entire jobs won’t work.

[jonico]

You can make an entire job optional based on the presence of a secret if you had a previous job that set a job output: https://gist.github.com/jonico/24ffebee6d2fa2e679389fac8aef50a3

[GabLeRoux]

Thanks jonico, I’ve created a more specific example here:
https://github.com/GabLeRoux/github-actions-examples/blob/e0468ce2731b08bd8b1f7cd09d0b94c541310693/.github/workflows/secret_based_conditions.yml

[TomerFi]

This did the trick for me:

- name: Clean local maven repository
  env:
    CLEAN_MVN_REPO: ${{ secrets.CLEAN_MVN_REPO }}
  if: env.CLEAN_MVN_REPO != null
  run: rm -r ~/.m2/repository/*

If the secret called CLEAN_MVN_REPO doesn’t exist,
this step isn’t executed.

[stephan-rayner]

It may be a little cheeky but this is what I did at my org. I run a job before my main CI job that checks if all my secrets are in place. It normally does other things too but I took that out for the example below.

...
jobs:
preFlight:

name: "Preflight Checks"

runs-on: ubuntu-latest

steps:
- name: Assert Secrets Present
  shell: bash
  run: |
    MD5() {
      result=($(md5sum <(echo "${1}")))
      echo $result
    }

    secretPresent() {
      emptyHash=$(MD5 "")
      secretHash=$(MD5 "${1}")
      ! diff <(echo $secretHash) <(echo $emptyHash) &> /dev/null
    }

    errorMessage() {
      echo "Your secret ${1} seems to be missing please contact the Central-OPs team"
      return 1
    }

    secretStatus=0

    secretPresent "${{ secrets.GIT_TOKEN }}" || errorMessage "GIT_TOKEN" || secretStatus=1
    secretPresent "${{ secrets.AWD_KEY }}" || errorMessage "AWS_KEY" || secretStatus=2
    secretPresent "${{ secrets.THING_URL }}" || errorMessage "THING_URL" || secretStatus=3
    secretPresent "${{ secrets.THING_USER_TOKEN }}" || errorMessage "THING_USER_TOKEN" || secretStatus=4
    secretPresent "${{ secrets.CHEESE }}" || errorMessage "CHEESE" || secretStatus=5

    exit $secretStatus

- run: echo "Everything Checks Out 👍"

build:

needs: preFlight

name: "Build and Push to Registry"

runs-on: ubuntu-latest

steps:
- name: Checkout Code Base
  uses: actions/checkout@v2

...

That said I also really like the solution by tomerfi.

[lbergelson]

Thank you all for the workarounds, but this is ridiculous, there should be a top level github.secrets_present variable or something similar. I don’t understand why these extremely basic issues haven’t been addressed by github.

[swissbuechi]

I solved it the following way:

...
      - name: myjob
        env:
          MY_SECRET: ${{ secrets.MY_SECRET }}
        if: env.MY_SECRET != null
        run: echo "running"
...

Credits to @TomerFi and @ojeytonwilliams

Do you guys have any security concerns? Is it save to expose a secret as a local environment variable during a step?

[TomerFi]

I think GitHub consilds the secrets content in logs and outputs.
Other then that, it's quite a common technique I think, especially for actions that take their arguments via environment variables and not via the action's spec (the with directive).

[MikeMcC399]

https://stackoverflow.com/questions/70249519/how-to-check-if-a-secret-variable-is-empty-in-if-conditional-github-actions also suggests a workaround for this issue.

GH Actions: Context backs up what @Yanjingzhu wrote.

[tomas-pajurek]

I have recently also struggled with this and came up with the solution involving github.secret_source property. I am explaining this in the StackOverflow question you referenced.