Inconsistent allowed contexts for reusable workflow secrets/inputs
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 72/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- markdown
- Domain
- documentation
Research direction
Start by comparing actions/reference/workflows-and-actions/contexts.md with actions/reference/workflows-and-actions/reusable-workflows.md, focusing on the jobs.<job_id>.secrets.<secret_id> and jobs.<job_id>.with.<input_id> entries. Resolve the documented allowed contexts and align the workflow key names so both pages describe the same behavior.
Written by the indexing model from the issue text.
Description
Code of Conduct
- I have read and agree to the GitHub Docs project's Code of Conduct
What article on docs.github.com is affected?
- https://docs.github.com/en/actions/reference/workflows-and-actions/contexts
- https://docs.github.com/en/actions/reference/workflows-and-actions/reusable-workflows
What part(s) of the article would you like to see updated?
I have found inconsistencies between the actions/reference/workflows-and-actions/contexts.md and the actions/reference/workflows-and-actions/reusable-workflows.md pages.
The reusable-workflows.md page defines contexts for jobs.<job_id>.secrets.<secret_id> and jobs.<job_id>.with.<input_id> like so:
## `jobs.<job_id>.with.<input_id>`
[...]
Allowed expression contexts: `github`, and `needs`.
## `jobs.<job_id>.secrets.<secret_id>`
[...]
Allowed expression contexts: `github`, `needs`, and `secrets`.
This seems to match observed behavior that the following using After testing in a different and cleaner environment, this actually does not match the observed behavior, as the following using vars, using a reusable workflow that requires a secret, does not work:vars, using a reusable workflow that requires a secret, does work:
jobs:
job:
uses: job.yml
secrets:
MY_SECRET: ${{ vars.MY_SECRET }}
Indeed, the contexts.md page defines these contexts like so:
| `jobs.<job_id>.secrets.<secrets_id>` | `github, needs, strategy, matrix, secrets, inputs, vars` | None |
| `jobs.<job_id>.with.<with_id>` | `github, needs, strategy, matrix, inputs, vars` | None |
So I would have expected vars to work in this context, but it does not.
Also while we are at it, note the workflow keys are not consistent: secrets_id vs secret_id, and with_id vs input_id.
Therefore I would suggest to:
- Rename the workflow keys in the
contexts.mdpage to match those in thereusable-workflows.mdpage, - Update the "allowed expression contexts" in the
reusable-workflows.mdpage to match what is described in thecontexts.mdpage.
Additional information
No response
- Dominant language
- TypeScript
- Stars
- 20.9k
- Forks
- 68.8k
- Avg merge
- 15h 4m
- Merged PRs (30d)
- 103
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from github/docs
-
builder persona content
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
localization
Difficulty 2/5 1-2 days Newbie friendliness 72/100
-
builder persona
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
content localization
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
content localization
Difficulty 1/5 Under an hour Newbie friendliness 92/100
Similar issues
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 91/100
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Automattic/studio#4908 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100