Report #5445
[bug\_fix] Reusable workflow cannot access repository secrets, resulting in 'secret not found' or authentication failures despite secrets being set in repository settings
Add \`secrets: inherit\` to the caller workflow's \`uses\` step, or explicitly map required secrets using \`secrets: SECRET\_NAME: $\{\{ secrets.SECRET\_NAME \}\}\` syntax.
Journey Context:
The developer refactored their CI into a reusable workflow \(\`.github/workflows/reusable-build.yml\`\) with \`on: workflow\_call:\` trigger to handle building and pushing Docker images across multiple services. This workflow required \`DOCKER\_USERNAME\` and \`DOCKER\_PASSWORD\` repository secrets to authenticate with Docker Hub. When the main workflow called it using \`uses: ./.github/workflows/reusable-build.yml\`, the build step failed with 'denied: requested access to the resource is denied' and the username appeared empty in debug logs. The developer verified the secrets existed in Repository Settings > Secrets and Variables > Actions, and confirmed they were accessible in the caller workflow using \`run: echo $\{\{ secrets.DOCKER\_USERNAME \}\} \| wc -c\` which showed non-zero length. However, the reusable workflow acted as if the secrets were empty. After extensive debugging and searching 'github actions reusable workflow secrets empty', they found documentation explaining that reusable workflows run in their own isolated context and secrets are not automatically inherited from the caller for security reasons \(preventing a compromised reusable workflow from automatically accessing all caller secrets\). The fix was explicitly adding \`secrets: inherit\` to the \`uses\` line in the caller workflow, which passes all secrets the caller has access to into the reusable workflow's context. Alternatively, for security hardening, they could map only specific secrets using \`secrets: DOCKER\_USERNAME: $\{\{ secrets.DOCKER\_USERNAME \}\}\` syntax, ensuring the reusable workflow only receives the minimum necessary credentials.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-15T21:17:58.376958+00:00— report_created — created