-
Notifications
You must be signed in to change notification settings - Fork 60.3k
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
Document how to skip a step if a secret isn't present #6861
Comments
Thanks for opening an issue @jsoref! I'll triage this for the team to take a look 👀 |
Thank you for opening this issue! I have modified your suggestion for how to change the docs:
You or anyone else is welcome to open a PR to make these changes. |
This comment has been minimized.
This comment has been minimized.
I might do it at some point, but I'm hoping someone will pick it up first... |
… workflows (#12722) * 🔒 Document how to use secrets with `if:` #6861 #12722 - Add a complete workflow example to `jobs.<job_id>.steps[*].if`, demonstrating how to skip a step if a secret is not present - Add an explanation to "Using encrypted secrets in a workflow" - Cross-reference the two pages * 🔒 Compare secrets with empty strings in `if:` #6861 #12722 (comment) Rather than referencing two secrets: 1. `${{ secrets.SECRET_IS_SET }}` 2. `${{ secrets.SECRET_IS_NOT_SET }}`) This commit will update the related section of the docs to reference a single secret (`${{ secrets.SECRET_IS_SET }}`), and will update the `if:` conditionals to compare with empty strings as suggested. * 🔒 Add missing `{% raw %}`/`{% endraw %}` #6861 #12722 Some `${{ }}` values were converted to `$` in the preview environment. Adding `{% raw %}`/`{% endraw %}` will preserve the raw value. * 🔒 Match variable and secret names in examples #6861 #12722 (comment) This PR adds an example of how to use secrets with `if:` conditionals. The reviewer suggested comparing variable values with empty strings to make the `if:` conditionals clearer. Commit cecdf00 updated the secret names accordingly, but the names of the secret and environment variable may still have been confusing. This commit will update the secret and environment variable names to match the cross-referenced example on the "Encrypted secrets" page. * Update content/actions/using-workflows/workflow-syntax-for-github-actions.md Co-authored-by: hubwriter <hubwriter@github.com>
* 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
As mentioned in github/docs#6861: > It is common for projects to include a secret for deploying things and an action that uses that secret. > > When one forks that repository, the secret won't be present and the workflow will break. > > This experience is incredibly painful. For guardian/frontend, we're using [actions-riff-raff](https://github.com/guardian/actions-riff-raff), which needs a `roleArn` which is provided as a repository secret. For PRs like #27233, from an external contributor, the CI appears to fail, even though all tests have passed. ### CI never runs on forks unless we authorise the contributor The [GitHub docs](https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks#approving-workflow-runs-on-a-pull-request-from-a-public-fork) say: > By default, all first-time contributors require approval to run workflows. ...so it could be argued that ideally, the build should still produce the riff-raff artifact for fork PRs.
What article on docs.github.com is affected?
https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsif
https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions
https://docs.github.com/en/actions/reference/encrypted-secrets
What part(s) of the article would you like to see updated?
if
set should mention thatsecrets.
isn't availablesecrets.
isn't available inif
Additional information
It is common for projects to include a secret for deploying things and an action that uses that secret.
When one forks that repository, the secret won't be present and the workflow will break.
This experience is incredibly painful.
With just a bit of extra code in a workflow, the ❌ 's go away. But, w/o documentation on how to do it, 99% of workflow authors won't.
Here's an example which fixed one (of a number of failing workflows):
jsoref/argo-cd@ae52e40
The text was updated successfully, but these errors were encountered: