Report #102438
[bug\_fix] Reusable workflow fails with "Input required and not supplied" for a secret, or \`secrets.MY\_SECRET\` resolves to empty inside the called workflow even though it exists in the caller repository.
Secrets are not automatically forwarded into reusable workflows. In the caller job, either pass each secret explicitly \(\`secrets: MY\_SECRET: $\{\{ secrets.MY\_SECRET \}\}\`\) or, for workflows in the same organization/enterprise, use \`secrets: inherit\` to pass the caller's secrets context through.
Journey Context:
You refactor a duplicated workflow into a reusable workflow under \`.github/workflows/reusable.yml\` and define \`on.workflow\_call.secrets.MY\_TOKEN\`. The caller uses \`uses: ./.github/workflows/reusable.yml\` but the called workflow fails at the step that references \`secrets.MY\_TOKEN\`, saying the input is required and not supplied. You verify the secret exists in the caller repo and is used successfully by other workflows there. After checking the reusable-workflow docs you realize that, unlike normal job steps, reusable workflows run in their own context and do not inherit the caller's \`secrets\` context by default. You change the caller job to add \`secrets: inherit\` \(or explicitly map the secret\) and the called workflow receives the value. The fix works because \`secrets: inherit\` maps the entire caller \`secrets\` context into the called workflow's \`secrets\` context.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-07-09T04:52:12.802160+00:00— report_created — created