Allow skipping a job based on whether there is permission to access certain secrets

[ismay]

Describe the enhancement

Allow skipping a job based on whether there is permission to access a certain secret

Code Snippet

Currently, this is the most readable, concise way I've found of conditionally running jobs that need secrets (which checks exactly for the secrets that each job needs):

jobs:
  secrets:
    runs-on: ubuntu-latest
    outputs:
      HAS_PERCY_TOKEN: ${{ steps.check.outputs.PERCY_TOKEN }}
      HAS_GITHUB_TOKEN: ${{ steps.check.outputs.GITHUB_TOKEN }}
    steps:
      - run: >
          echo "::set-output name=PERCY_TOKEN::${{ env.PERCY_TOKEN != '' }}";
          echo "::set-output name=GITHUB_TOKEN::${{ env.GITHUB_TOKEN != '' }}";
        id: check
        env:
          PERCY_TOKEN: ${{ secrets.PERCY_TOKEN }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  job1:
    needs: ["secrets"]
    if: >
      needs.secrets.outputs.HAS_PERCY_TOKEN == 'true' &&
      needs.secrets.outputs.HAS_GITHUB_TOKEN == 'true'
    runs-on: ubuntu-latest
    steps:
        # Steps here
        env:
          PERCY_TOKEN: ${{ secrets.PERCY_TOKEN }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  job2:
    needs: ["secrets"]
    if: >
      needs.secrets.outputs.HAS_GITHUB_TOKEN == 'true'
    runs-on: ubuntu-latest
    steps:
        # Steps here
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

There are other ways of course, but my point is they all basically involve a lot of repetitive code. It is a very common usecase to check for the existence of a secret before running a job, as your workflows could potentially also be started by dependabot, or from a fork. But currently it is just way too cumbersome to do so. Plus it is polluting my action logs with a lot of near identical jobs that all check for secrets before a certain workflow runs (which is obscuring the info I really want to see).

My feature request is to allow for a more concise way to conditionally run a job depending on whether it has access to one or more secrets. So basically the functionality from the code sample above, but ideally just in the if condition of the job that needs the secrets (or potentially configured in another manner, as long as it cuts down on the above boilerplate).

Additional information

I'm not the only one who really wants this, see these issues and questions that all deal with this topic:

• Secrets cannot be used to condition job runs #520
• Add a function for testing if a secret exists #953
• https://github.community/t/how-can-i-test-if-secrets-are-available-in-an-action/17911/10
• https://github.community/t/jobs-job-id-if-does-not-work-with-env-secrets/16928/8

For a real-world example, see the workflows in this repo for example: https://github.com/ismay/superwolff/tree/55b76c6c4284021193c9dc920cde7a2de03c9522/.github/workflows. Which has 5 workflows, of which 4 have to implement almost the exact same boilerplate just to check whether secrets are available.

edit: seems slightly related to #662

edit 2: another approach that a lot of people use is using a condition like github.repository_owner == '<USERNAME_HERE>' && github.actor != 'dependabot[bot]'. This is a lot more concise than the example above and works well. However, it's a slightly indirect manner of checking for secrets. I still think the clearest solution here would be for github to expose a value that we can check against, to see whether secrets are available or not. That would allow checking for exactly what you're interested in, instead of having to check for the existence of secrets in a roundabout manner.

[ethomson]

Thanks for the feedback @ismay, I've run into this problem myself. I'll put this on the backlog.

[ismay]

Thanks for the feedback @ismay, I've run into this problem myself. I'll put this on the backlog.

Thanks!