A run whose workflow lists a secret it is not given now says so at the top of its log, before the steps: ==> NPM_TOKEN is not granted to <repo> at <ref>. A pull's or merge-queue batch's run, which gets no secrets, says ==> NAME is not granted to a pull's or a merge-queue batch's run, which gets no secrets. The line names the secret, never a value. docs/design/runner.md and docs/reference/workflows.md say so.
Why
A secret not granted was simply absent, so a release workflow failed somewhere in its steps with nothing saying why. This is the first part of the design on the issue below, and useful on its own; the rest (owners sealing secrets to a runner) follows in its own pulls.
tests/run.rs: the push run's log names UNGRANTED and TAGS_ONLY (granted only to tags) and not the granted TOKEN; a pull's run of a workflow asking for TOKEN says it gets none. Left to CI.
What changes
A run whose workflow lists a secret it is not given now says so at the top of its log, before the steps:
==> NPM_TOKEN is not granted to <repo> at <ref>. A pull's or merge-queue batch's run, which gets no secrets, says==> NAME is not granted to a pull's or a merge-queue batch's run, which gets no secrets. The line names the secret, never a value.docs/design/runner.mdanddocs/reference/workflows.mdsay so.Why
A secret not granted was simply absent, so a release workflow failed somewhere in its steps with nothing saying why. This is the first part of the design on the issue below, and useful on its own; the rest (owners sealing secrets to a runner) follows in its own pulls.
Part of A repository owner can't give the hosted runner a secret
How it was checked
tests/run.rs: the push run's log namesUNGRANTEDandTAGS_ONLY(granted only to tags) and not the grantedTOKEN; a pull's run of a workflow asking forTOKENsays it gets none. Left to CI.🤖 Generated with Claude Code