Report #72483
[bug\_fix] Downstream job receives empty string when accessing \`needs.build.outputs.output\_name\` even though the upstream step set it via \`echo "key=value" >> $GITHUB\_OUTPUT\`
Explicitly map step outputs to job outputs in the upstream job using the \`outputs:\` section at the job level: \`outputs: output\_name: $\{\{ steps.step\_id.outputs.output\_name \}\}\`. Root cause: Step outputs are scoped to the job execution and do not automatically propagate as job outputs. You must explicitly declare job-level outputs that reference step-level outputs using the specific mapping syntax for the \`needs\` context to access them.
Journey Context:
A developer has a "build" job that determines a version number in a step with \`id: version\` and \`run: echo "version=1.0.0" >> $GITHUB\_OUTPUT\`. They have a downstream "deploy" job with \`needs: build\` that attempts to use \`needs.build.outputs.version\` in a deployment script. The deploy job runs but the version variable is empty. The developer checks the build job logs and confirms the step output is set correctly. They try different syntax like \`$\{\{ needs.build.outputs.version \}\}\` but still get nothing. They search documentation and realize that while step outputs are set via \`GITHUB\_OUTPUT\`, job outputs require an explicit declaration. They add to the build job definition: \`outputs: version: $\{\{ steps.version.outputs.version \}\}\`. When the workflow runs again, the deploy job successfully receives "1.0.0" because the job-level \`outputs\` declaration explicitly exposes the step's internal output to the \`needs\` context, making it available to downstream jobs.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T04:15:05.197429+00:00— report_created — created