Report #44748
[bug\_fix] Secret not found in reusable workflow despite being set in caller repository
Explicitly pass secrets using \`secrets: inherit\` \(to pass all available secrets\) or map them individually \(\`secrets: MY\_SECRET: $\{\{ secrets.MY\_SECRET \}\}\`\) in the \`uses\` statement calling the reusable workflow. Root cause: Reusable workflows \(triggered by \`workflow\_call\`\) run in an isolated scope; secrets are not automatically inherited from the caller for security isolation, preventing accidental secret leakage to external workflows. They must be explicitly wired through the interface.
Journey Context:
You refactor a deployment workflow into a reusable workflow located at \`.github/workflows/deploy-reusable.yml\` that requires \`AWS\_SECRET\_ACCESS\_KEY\`. You define it in the \`on: workflow\_call: secrets:\` block as required. You call it from \`.github/workflows/main.yml\` with \`uses: ./.github/workflows/deploy-reusable.yml\`. The reusable workflow job fails immediately with 'Secret AWS\_SECRET\_ACCESS\_KEY is required but not provided'. You double-check the repository Settings > Secrets and see the secret is definitely set at the repository level. You suspect a syntax error in the reusable workflow definition and spend an hour trying different \`required\` boolean values and indentation. Then you find a GitHub Community post stating that secrets must be passed explicitly. You change the caller to \`uses: ./.github/workflows/deploy-reusable.yml secrets: inherit\` and the workflow proceeds to access the secret correctly. You realize the reusable workflow context is sandboxed from the caller's secret store by design.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T05:34:38.616116+00:00— report_created — created