Code of Conduct
What article on docs.github.com is affected?
https://docs.github.com/en/actions/sharing-automations/reusing-workflows
Specifically the Using inputs and secrets in a reusable workflow section.
What problem is this issue addressing?
The current docs assert:
"If a called workflow needs to access environment secrets, the environment must be defined in the called workflow."
This implies that declaring environment: on the called workflow's job is sufficient to resolve environment-scoped secrets via ${{ secrets.X }}. Empirically it is not sufficient — secrets: inherit on the caller is also required, otherwise every environment-scoped secret resolves to "" (empty string) at the called workflow's runtime.
Filed as a behavior bug at actions/runner#4453 with a minimal reproduction. Whether the right fix is in the runner or in the docs, this page currently leads users to ship broken configurations.
What is the proposed solution?
Either:
(a) If the runner team treats #4453 as expected behavior — clarify the docs:
"If a called workflow needs to access environment secrets, the environment must be defined in the called workflow AND the caller must use secrets: inherit (or pass the secrets explicitly via secrets:). Declaring environment: alone in the called workflow is not sufficient for env-scoped secret resolution."
Add a short callout block warning that this is a common silent-failure mode — secrets resolve to "" rather than raising any error.
(b) If the runner team fixes #4453 — remove the warning once the behavior matches the original docs assertion.
Additional information
- Real-world incident: a production CI/CD pipeline using this pattern across ~12 tenants shipped to staging with all environment secrets resolving empty. The failure was masked for ~9 days because legacy in-cluster Kubernetes Secrets bridged the gap on existing pods (env-from only injects at pod start). The first deploy that triggered fresh pods on a non-legacy Secret crashlooped loudly.
- The fact that env binding takes effect for
vars (environment variables) but NOT for secrets in this scenario is particularly confusing — both should behave consistently.
Code of Conduct
What article on docs.github.com is affected?
https://docs.github.com/en/actions/sharing-automations/reusing-workflows
Specifically the Using inputs and secrets in a reusable workflow section.
What problem is this issue addressing?
The current docs assert:
This implies that declaring
environment:on the called workflow's job is sufficient to resolve environment-scoped secrets via${{ secrets.X }}. Empirically it is not sufficient —secrets: inheriton the caller is also required, otherwise every environment-scoped secret resolves to""(empty string) at the called workflow's runtime.Filed as a behavior bug at actions/runner#4453 with a minimal reproduction. Whether the right fix is in the runner or in the docs, this page currently leads users to ship broken configurations.
What is the proposed solution?
Either:
(a) If the runner team treats #4453 as expected behavior — clarify the docs:
Add a short callout block warning that this is a common silent-failure mode — secrets resolve to
""rather than raising any error.(b) If the runner team fixes #4453 — remove the warning once the behavior matches the original docs assertion.
Additional information
vars(environment variables) but NOT forsecretsin this scenario is particularly confusing — both should behave consistently.