Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Secrets cannot be used to condition job runs #520

Closed
mzabaluev opened this issue Jun 8, 2020 · 22 comments
Closed

Secrets cannot be used to condition job runs #520

mzabaluev opened this issue Jun 8, 2020 · 22 comments
Labels
question Further information is requested

Comments

@mzabaluev
Copy link

Describe the bug
The secrets context is apparently not available to if conditional expressions on jobs.

To Reproduce
Create and trigger a workflow with jobs conditioned on the value of a secret:

jobs:
  build_bulky_stuff:
    if: ${{ secrets.BUILD_BULKY_STUFF == 'true' }}
    # ...

Here's a real world example.

Expected behavior
The condition is successfully evaluated and if the secret value is set to 'true', the job is run.

Runner Version and Platform

Version of your runner? No idea, GitHub hosted.

OS of the machine running the runner? Linux

What's not working?

The workflow fails with:

The workflow is not valid. .github/workflows/release.yml (Line: 11, Col: 9): Unrecognized named-value: 'secrets'. Located at position 1 within expression: secrets.BUILD_RELEASES == 'true',.github/workflows/release.yml (Line: 35, Col: 9): Unrecognized named-value: 'secrets'. Located at position 1 within expression: secrets.BUILD_RELEASES == 'true'

Job Log Output

See this workflow run

@mzabaluev mzabaluev added the bug Something isn't working label Jun 8, 2020
@TingluoHuang
Copy link
Member

I don't think we should support secrets in if conditional expression since you can't debug the expression evaluation result.

Today we printout debug info for evaluating condition, so when the condition result is not what you expected, you can base on the log to figure out whether it's a bug in the system or you provide the wrong input.

Ex:

##[debug]Evaluating: (success() && (runner.os != 'Windows'))
##[debug]Evaluating And:
##[debug]..Evaluating success:
##[debug]..=> true
##[debug]..Evaluating NotEqual:
##[debug]....Evaluating Index:
##[debug]......Evaluating runner:
##[debug]......=> Object
##[debug]......Evaluating String:
##[debug]......=> 'os'
##[debug]....=> 'macOS'
##[debug]....Evaluating String:
##[debug]....=> 'Windows'
##[debug]..=> true
##[debug]=> true
##[debug]Expanded: (true && ('macOS' != 'Windows'))
##[debug]Result: true

@TingluoHuang TingluoHuang added the question Further information is requested label Jun 8, 2020
@mzabaluev
Copy link
Author

I see. I assumed the secrets can be used in lieu of per-repository configuration values settable by the administrator, similar to how the ACTIONS_STEP_DEBUG secret is used by the runner to enable logs.

My need is to disable costly and potentially annoying actions in forks, unless the administrator of the fork enables them. We currently use if: ${{ github.repository_owner == 'our_org' }}, but it is annoying to have to disable these conditions in the workflow file when you need to test the workflows.

@TingluoHuang
Copy link
Member

TingluoHuang commented Jun 8, 2020

@mzabaluev you can do something like this.

if: ${{ github.repository_owner == 'our_org' || contains(github.event.head_commit.message, 'RUN TEST')}}

then if you want to run those costly steps, just put RUN TEST as part of your commit message.

I hope this can help.

@cjolowicz
Copy link

@TingluoHuang My use case is slightly different: I would like to skip steps that interact with an external service e.g. package repository if the API token is not present. It would be enough to be able to check if the secret exists, without inspecting the value. Any chance of that happening? It would be especially useful for project templates: Users often push their projects to a new GitHub repository before configuring the secrets.

@quisse
Copy link

quisse commented Sep 29, 2020

Did anyone try assigning a secrets value to an output?

      - name: Assign variable
        id: secret
        run: echo '::set-output name=secret::${{secrets.SECRET}}'

      - name: Encode the project the project
        if: steps.secret.outputs.secret

@ejgyurisan
Copy link

Did anyone try assigning a secrets value to an output?

      - name: Assign variable
        id: secret
        run: echo '::set-output name=secret::${{secrets.SECRET}}'

      - name: Encode the project the project
        if: steps.secret.outputs.secret

You cannot use a secret in an output. Only star characters will be printed

@quisse
Copy link

quisse commented Nov 3, 2020

The output in the log will be hidden by * but the value in the output variable will be the same as the secret.

@ejgyurisan
Copy link

Ok, I only tried to use it as an output of a job, not a step, maybe that was the problem. Not sure.

bfirsh added a commit to bfirsh/keepsake that referenced this issue Nov 5, 2020
This will make dependabot run external tests.

It would be neat to just check if the secret exists, but you can't
do that in an if expression: actions/runner#520

Signed-off-by: Ben Firshman <ben@firshman.co.uk>
nomeata added a commit to entropia/tip-toi-reveng that referenced this issue Nov 28, 2020
carlobeltrame added a commit to carlobeltrame/ecamp3 that referenced this issue Dec 20, 2020
Forks don't have access to the main repo's secrets. When a branch on a
fork is pushed to, CI still runs, but the last step of sending out the
CI success event shouldn't happen there (unless the fork owner defines
his own REPO_ACCESS_TOKEN in the fork's secrets).

Unfortunately, GitHub Actions currently does not support checking the
presence of a secret in a conditional (see
actions/runner#520). So for now, we just check
whether we are in the origin by checking the repo owner.
johnsca added a commit to charmed-kubernetes/actions-operator that referenced this issue May 17, 2021
berberman added a commit to berberman/haskell-language-server that referenced this issue May 19, 2021
jon-turney added a commit to jon-turney/meson that referenced this issue May 23, 2021
Use the respository owner name rather than hardcoding 'mesonbuild'

Don't run this workflow if docker credentials aren't in secrets
(has to be written rather indirectly due to actions/runner#520)
jon-turney added a commit to jon-turney/meson that referenced this issue May 23, 2021
Use the respository owner name rather than hardcoding 'mesonbuild'

Also don't try to push to docker if docker credentials aren't in secrets
(has to be written rather indirectly due to actions/runner#520)
jon-turney added a commit to jon-turney/meson that referenced this issue Jun 3, 2021
The 'build images' workflow runs on a schedule, so will run (and fail)
weekly in every fork.

Don't try to push to docker if docker credentials aren't in repository
secrets.

(A test for that has to be written rather indirectly due to
actions/runner#520)
jon-turney added a commit to jon-turney/meson that referenced this issue Jun 3, 2021
The 'build images' workflow runs on a schedule, so will run (and fail)
weekly in every fork.

Don't try to push to docker if docker credentials aren't in repository
secrets.

(A test for that has to be written rather indirectly due to
actions/runner#520)
Finii added a commit to Finii/nerd-fonts that referenced this issue Aug 26, 2022
[why]
I am sure I tested it and it worked. Well, it does not, it throws an
error message
  Unrecognized named-value: 'secrets'

[how]
Secrets can not be used in the `if`, see
actions/runner#520

But they can be used in `env`, ... so do it there.

Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Finii added a commit to Finii/nerd-fonts that referenced this issue Aug 26, 2022
[why]
I am sure I tested it and it worked. Well, it does not, it throws an
error message
  Unrecognized named-value: 'secrets'

[how]
Secrets can not be used in the `if`, see
actions/runner#520

But they can be used in `env`, ... so do it there.

Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Finii added a commit to ryanoasis/nerd-fonts that referenced this issue Aug 26, 2022
[why]
I am sure I tested it and it worked. Well, it does not, it throws an
error message
  Unrecognized named-value: 'secrets'

[how]
Secrets can not be used in the `if`, see
actions/runner#520

But they can be used in `env`, ... so do it there.

Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
chabala added a commit to chabala/brick-control-lab that referenced this issue Feb 11, 2023
* move Coveralls to conditional job based on secret availability
** also discovered Coveralls Github Action doesn't work with Java ☹️
* add preconditional secret check job for Sonar
* GitHub Actions conditional flow is a lot of work:
github/docs#6861
actions/runner#520
actions/runner#953
actions/runner#1138
jan-molak added a commit to serenity-js/serenity-js that referenced this issue Apr 15, 2023
paulswartz added a commit to mbta/workflows that referenced this issue Jul 5, 2023
This avoids failures when running on PRs from forks.

We do it in this convoluted way because you can't access secrets
directly from `if` blocks: actions/runner#520
paulswartz added a commit to mbta/workflows that referenced this issue Jul 24, 2023
This avoids failures when running on PRs from forks.

We do it in this convoluted way because you can't access secrets
directly from `if` blocks: actions/runner#520
paulswartz added a commit to mbta/workflows that referenced this issue Aug 7, 2023
This avoids failures when running on PRs from forks.

We do it in this convoluted way because you can't access secrets
directly from `if` blocks: actions/runner#520
paulswartz added a commit to mbta/workflows that referenced this issue Aug 7, 2023
This avoids failures when running on PRs from forks.

We do it in this convoluted way because you can't access secrets
directly from `if` blocks: actions/runner#520

The key differences between this and
#14 are:
- typo: should be `outputs` in the `if` blocks
- more explicity check for the secrets in a Bash script, so we can see
the output
- use `yes` instead of `true` as the value to more clearly distinguish
the value from a true boolean
paulswartz added a commit to mbta/workflows that referenced this issue Aug 7, 2023
This avoids failures when running on PRs from forks.

We do it in this convoluted way because you can't access secrets
directly from `if` blocks: actions/runner#520

The key differences between this and
#14 are:
- typo: should be `outputs` in the `if` blocks
- more explicity check for the secrets in a Bash script, so we can see
the output
- use `yes` instead of `true` as the value to more clearly distinguish
the value from a true boolean
paulswartz added a commit to mbta/workflows that referenced this issue Aug 7, 2023
This avoids failures when running on PRs from forks.

We do it in this convoluted way because you can't access secrets
directly from `if` blocks: actions/runner#520

The key differences between this and
#14 are:
- typo: should be `outputs` in the `if` blocks
- more explicity check for the secrets in a Bash script, so we can see
the output
- use `yes` instead of `true` as the value to more clearly distinguish
the value from a true boolean
paulswartz added a commit to mbta/workflows that referenced this issue Aug 7, 2023
This avoids failures when running on PRs from forks.

We do it in this convoluted way because you can't access secrets
directly from `if` blocks: actions/runner#520

The key differences between this and
#14 are:
- typo: should be `outputs` in the `if` blocks
- more explicity check for the secrets in a Bash script, so we can see
the output
- use `yes` instead of `true` as the value to more clearly distinguish
the value from a true boolean
@ReenigneArcher
Copy link

In my case I wanted to check if a secret was null to enable disable a matrix job.

I thought this would work: if: secrets.SOMETHING != null would be sufficient; however I guess I was mistaken.

Anyway, this will not work. It will be true for every PR, even from outside collaborators.

if: github.repository_owner == 'our_org'

I ended up using this.

if: >-
  (github.event_name == 'pull_request' && github.event.pull_request.head.owner.login == 'org_name') ||
  (github.event_name == 'push' && github.ref == 'refs/heads/master')

If a pull request, the head owner must be our Org. (only issue is some org members work in their own forks)... or if a push to the default branch it will evaluate to true.

Another alternative is probably this.

if: github.secret_source == 'Actions'

or

if: github.secret_source != 'None'

Hope this is helpful for others.

LNKLEO pushed a commit to LNKLEO/Nerd that referenced this issue Nov 24, 2023
[why]
I am sure I tested it and it worked. Well, it does not, it throws an
error message
  Unrecognized named-value: 'secrets'

[how]
Secrets can not be used in the `if`, see
actions/runner#520

But they can be used in `env`, ... so do it there.

Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
codemonkey800 added a commit to chanzuckerberg/cryoet-data-portal that referenced this issue Feb 29, 2024
Fixes issue with prod deploy due to secrets not being available for job
conditionals: actions/runner#520

This switches to using a repository variable which should be appropriate
since the value can only be `true` or `false`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests