Report #69528
[bug\_fix] Reusable workflow fails to access secrets with 'Unrecognized named-value: secrets' or empty secret values
Secrets are not automatically inherited by reusable workflows \(called via \`uses:\`\). The caller workflow must explicitly pass secrets using \`secrets: inherit\` \(to pass all secrets\) or map them individually with \`secrets: SECRET\_NAME: $\{\{ secrets.SECRET\_NAME \}\}\`. Without this, the \`secrets\` context is empty or inaccessible in the called workflow, causing authentication or configuration failures.
Journey Context:
A developer refactors duplicated CI logic across multiple services into a reusable workflow stored at \`.github/workflows/deploy-reusable.yml\`. This workflow handles Docker build and push to a registry requiring \`secrets.DOCKER\_PASSWORD\`. The caller workflow uses \`uses: ./.github/workflows/deploy-reusable.yml\` and passes inputs like \`image\_name\`, but when the reusable workflow runs, the Docker login step fails with 'Error: Password required'. The developer checks the caller workflow's \`env\` and \`secrets\` context at the top level, confirming the secret exists. They try referencing the secret in the caller and passing it as an \`input\`, but inputs are not masked in logs like secrets. They search for 'reusable workflow secrets empty' and find documentation stating that reusable workflows have an isolated \`secrets\` context. They discover the \`secrets: inherit\` syntax or the explicit mapping syntax. They update the caller workflow to include \`secrets: inherit\` \(since they want to pass all secrets\) or explicitly \`secrets: DOCKER\_PASSWORD: $\{\{ secrets.DOCKER\_PASSWORD \}\}\`. The reusable workflow now receives the secret in its \`secrets\` context, the Docker login succeeds, and the image pushes to the registry.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T23:11:19.228439+00:00— report_created — created