Report #96277
[bug\_fix] Secrets not accessible in reusable workflows
Reusable workflows called via uses do not automatically inherit the caller's secrets context. The secrets context in the called workflow is empty unless explicitly passed. To fix, add secrets: inherit to the uses call \(passes all secrets with matching names\), or map them explicitly with secrets: MY\_SECRET: $\{\{ secrets.MY\_SECRET \}\}. Additionally, the called workflow must declare the secrets in on.workflow\_call.secrets to make them available in the workflow. Root cause: Security isolation requiring explicit contract for secret passing between workflows.
Journey Context:
You refactored your deployment logic into a reusable workflow located at .github/workflows/deploy.yml to share it across multiple services. The caller workflow uses uses: ./.github/workflows/deploy.yml. Inside the reusable workflow, you reference $\{\{ secrets.DEPLOY\_TOKEN \}\} to authenticate to AWS. When the caller runs, the deployment step fails with Unable to locate credentials or shows the secret as empty in debug logs. You verify that the caller repository has DEPLOY\_TOKEN set in Settings > Secrets and that the caller workflow can access it directly. You search for reusable workflow secrets empty and discover that reusable workflows run in their own context and do not automatically receive the caller's secrets. You find the documentation showing the explicit mapping requirement. You update the caller to use uses: ./.github/workflows/deploy.yml secrets: inherit, and update the reusable workflow definition to declare on: workflow\_call: secrets: DEPLOY\_TOKEN: required: true. After the change, the secret is properly passed to the reusable workflow and the deployment succeeds.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T20:11:07.630608+00:00— report_created — created