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

Document how to skip a step if a secret isn't present #6861

Closed
jsoref opened this issue May 28, 2021 · 4 comments · Fixed by #12722
Closed

Document how to skip a step if a secret isn't present #6861

jsoref opened this issue May 28, 2021 · 4 comments · Fixed by #12722
Labels
actions This issue or pull request should be reviewed by the docs actions team content This issue or pull request belongs to the Docs Content team help wanted Anyone is welcome to open a pull request to fix this issue

Comments

@jsoref
Copy link
Contributor

jsoref commented May 28, 2021

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?

  • Something in the if set should mention that secrets. isn't available
  • Something in the context set should mention that secrets. isn't available in if
  • Something in the three should explain how to work around this

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

      - name: deploy
        if: ${{ github.event_name == 'push' && env.HAVE_PERSONAL_TOKEN == 'true' }}
        uses: peaceiris/actions-gh-pages@v2.5.0
        env:
          HAVE_PERSONAL_TOKEN: ${{ secrets.PERSONAL_TOKEN != '' }}
          PERSONAL_TOKEN: ${{ secrets.PERSONAL_TOKEN }}
@jsoref jsoref added the content This issue or pull request belongs to the Docs Content team label May 28, 2021
@github-actions github-actions bot added the triage Do not begin working on this issue until triaged by the team label May 28, 2021
@janiceilene
Copy link
Contributor

Thanks for opening an issue @jsoref! I'll triage this for the team to take a look 👀

@janiceilene janiceilene added actions This issue or pull request should be reviewed by the docs actions team and removed triage Do not begin working on this issue until triaged by the team labels May 28, 2021
@skedwards88
Copy link
Contributor

Thank you for opening this issue! I have modified your suggestion for how to change the docs:

  1. We document that the secrets context is not available in if statements in the "Context availability" section of "Context and expression syntax for GitHub Actions", so I recommend leaving this article as is.

  2. I think you are right that we could additionally call this out in the "if" sections in Workflow syntax for GitHub Actions. For example, adding a sentence like

    Not all contexts are available to if statements.

    before

    For more information, see "Context and expression syntax for GitHub Actions."

  3. Additionally, I think you are right that users would find a workaround helpful given how many issues and discussions have been opened with this request. An example could be added to the end of the "Using encrypted secrets in a workflow" section in "Encrypted secrets", prefaced with a sentence describing the use case. Here is a simplified example:

on: push
jobs:
  my-jobname:
    runs-on: ubuntu-latest
    env:
       MY_SECRET: ${{ secrets.MY_SECRET }}
    steps:
      - if: ${{ env.MY_SECRET }}
        run: echo "I have the secret!"

You or anyone else is welcome to open a PR to make these changes.

@skedwards88 skedwards88 added the help wanted Anyone is welcome to open a pull request to fix this issue label Jun 29, 2021
@KingofAngma

This comment has been minimized.

@github-actions github-actions bot added the stale There is no recent activity on this issue or pull request label Oct 8, 2021
@jsoref
Copy link
Contributor Author

jsoref commented Oct 17, 2021

I might do it at some point, but I'm hoping someone will pick it up first...

@github-actions github-actions bot added the triage Do not begin working on this issue until triaged by the team label Oct 17, 2021
@ramyaparimi ramyaparimi removed triage Do not begin working on this issue until triaged by the team stale There is no recent activity on this issue or pull request labels Oct 18, 2021
@ramyaparimi ramyaparimi reopened this Oct 18, 2021
@github-actions github-actions bot added the triage Do not begin working on this issue until triaged by the team label Oct 18, 2021
@ramyaparimi ramyaparimi removed the triage Do not begin working on this issue until triaged by the team label Oct 18, 2021
hubwriter added a commit that referenced this issue Mar 18, 2022
… 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>
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
rtyley added a commit to guardian/frontend that referenced this issue Jul 25, 2024
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.
ukd1 added a commit to ukd1/canonical-rails that referenced this issue Aug 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
actions This issue or pull request should be reviewed by the docs actions team content This issue or pull request belongs to the Docs Content team help wanted Anyone is welcome to open a pull request to fix this issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants
@jsoref @janiceilene @skedwards88 @ramyaparimi @KingofAngma and others