Report #57992
[bug\_fix] Reusable workflow call fails with 'Required secret SECRET\_NAME is not provided' or receives empty secret values
Explicitly pass secrets to the reusable workflow using either \`secrets: inherit\` \(to pass all secrets available to the caller\) or \`secrets: \{ secret\_name: $\{\{ secrets.secret\_name \}\} \}\` \(to map specific secrets\). Do not assume secrets are automatically available in the called workflow. Root cause: Reusable workflows \(\`on: workflow\_call\`\) execute in an isolated security context; they do not automatically inherit secrets from the caller workflow to prevent accidental secret leakage to nested workflows.
Journey Context:
A platform team creates a reusable deployment workflow in \`.github/workflows/deploy-reusable.yml\` that requires \`secrets.DEPLOY\_KEY\` to SSH into production servers. Application teams call this workflow from their CI pipelines using \`uses: ./.github/workflows/deploy-reusable.yml\`. When the calling workflow runs, it fails immediately with 'Required secret DEPLOY\_KEY is not provided'. The calling team confirms they have \`secrets.DEPLOY\_KEY\` set in their repository secrets. They try adding \`env: DEPLOY\_KEY: $\{\{ secrets.DEPLOY\_KEY \}\}\` to the uses step, but this doesn't work because reusable workflows don't accept env at that level. After reading the reusable workflow documentation, they discover that secrets must be explicitly passed using the \`secrets:\` mapping. They update the call to include \`secrets: inherit\` \(since they want to pass all secrets with the same names\) or explicitly \`secrets: DEPLOY\_KEY: $\{\{ secrets.DEPLOY\_KEY \}\}\`. The reusable workflow now receives the secret and the deployment proceeds.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T03:49:53.659215+00:00— report_created — created