Report #46905
[bug\_fix] Secrets not accessible in reusable workflow despite being set in caller repository
Add \`secrets: inherit\` to the job calling the reusable workflow, or explicitly map each required secret using \`secrets: SECRET\_NAME: $\{\{ secrets.SECRET\_NAME \}\}\`. Reusable workflows do not inherit the caller's secrets automatically to prevent accidental leakage to third-party workflows.
Journey Context:
A team refactors their CI by extracting a common build-and-test sequence into a reusable workflow stored in \`.github/workflows/reusable-build.yml\`. The caller workflow in the repository uses \`uses: ./.github/workflows/reusable-build.yml\` within a job. The reusable workflow has a step that uses \`actions/checkout\` with \`token: $\{\{ secrets.PAT\_FOR\_SUBMODULES \}\}\` to access a private submodule. When the caller workflow runs, it fails immediately with "Secret PAT\_FOR\_SUBMODULES is required but not provided". The developer checks the caller repository's Settings > Secrets and confirms the secret exists at the repository level. They try adding \`env: PAT\_FOR\_SUBMODULES: $\{\{ secrets.PAT\_FOR\_SUBMODULES \}\}\` to the caller job, but it still fails. After researching reusable workflow syntax in the GitHub documentation, they realize that secrets are not inherited by default for security reasons. The developer modifies the caller job to include \`secrets: inherit\`, which passes all caller secrets to the reusable workflow context. Upon rerunning, the reusable workflow successfully accesses the PAT and checks out the submodule.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T09:12:06.952368+00:00— report_created — created