Report #103494
[bug\_fix] Reusable workflow fails with a missing secret even though the secret is set in the caller repository; \`$\{\{ secrets.MY\_SECRET \}\}\` is empty inside the called workflow.
Secrets are not automatically inherited by reusable workflows. In the caller job, either pass the secret explicitly with \`secrets: my\_secret: $\{\{ secrets.MY\_SECRET \}\}\` or, for reusable workflows in the same organization/enterprise, use \`secrets: inherit\` to pass all caller secrets. Also declare required secrets under \`on.workflow\_call.secrets\` in the reusable workflow.
Journey Context:
We refactored a deployment workflow into a reusable workflow in \`.github/workflows/deploy.yml\` and called it from the main workflow with \`uses: ./.github/workflows/deploy.yml\`. The deployment step uses \`DEPLOY\_TOKEN\` from \`secrets.DEPLOY\_TOKEN\`. When it was inline the secret worked; after moving it to a reusable workflow the step failed with 'token is required'. I verified the secret still existed in the repository settings and the job name was correct. Then I noticed the reusable workflow run's 'Set up job' step did not list \`DEPLOY\_TOKEN\` among available secrets. The root cause is that GitHub Actions isolates reusable workflows from the caller's secrets by default for security. The fix was to add \`secrets: inherit\` in the caller job \(since both workflows are in the same repository\), which made all repository secrets available to the called workflow. For cross-repository reusable workflows I now pass only the required secrets explicitly under \`secrets:\`. Declaring \`on.workflow\_call.secrets: DEPLOY\_TOKEN: required: true\` in the reusable workflow also makes the contract explicit and fails fast if it is missing.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-07-11T04:29:30.589793+00:00— report_created — created