-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Comments
I don't think we should support 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:
|
I see. I assumed the secrets can be used in lieu of per-repository configuration values settable by the administrator, similar to how the My need is to disable costly and potentially annoying actions in forks, unless the administrator of the fork enables them. We currently use |
@mzabaluev you can do something like this.
then if you want to run those costly steps, just put I hope this can help. |
@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. |
Did anyone try assigning a secrets value to an output?
|
You cannot use a secret in an output. Only star characters will be printed |
The output in the log will be hidden by |
Ok, I only tried to use it as an output of a job, not a step, maybe that was the problem. Not sure. |
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 <[email protected]>
following a trick learned from actions/runner#520
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.
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)
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)
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)
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)
[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 <[email protected]>
[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 <[email protected]>
[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 <[email protected]>
* 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
…n conditional statements see actions/runner#520
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
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
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
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
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
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
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
In my case I wanted to check if a secret was null to enable disable a matrix job. I thought this would work: 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. |
[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 <[email protected]>
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`
Describe the bug
The
secrets
context is apparently not available toif
conditional expressions on jobs.To Reproduce
Create and trigger a workflow with jobs conditioned on the value of a secret:
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:
Job Log Output
See this workflow run
The text was updated successfully, but these errors were encountered: