A reusable workflow invoked through workflow_call already declares an output under its on.workflow_call.outputs block that maps to a job output, so the value reaches callers. A calling workflow names the invoking job call-build and must read the returned build identifier in a separate deploy job. Which expression lets the caller's deploy job read that value?
- Asteps.call-build.outputs.build_id, after deploy lists call-build under needs, because the reusable workflow runs as a single step whose registered outputs are read through the steps context
- Bneeds.call-build.outputs.build_id, after deploy lists call-build under needs, because a reusable workflow's declared outputs surface on the calling job through the needs context Correct
- Cenv.build_id, with no needs entry on deploy, because the reusable workflow writes the identifier to GITHUB_ENV so every later job in the caller reads it from the env context
- Djobs.call-build.outputs.build_id, with no needs entry on deploy, because the calling workflow addresses other jobs and their outputs directly through the jobs context at run time
Why A is wrong: A reusable workflow is invoked as a job rather than a step, so its outputs are not available through the steps context of the calling deploy job.
Why B is correct: A reusable workflow exposes its workflow_call outputs on the calling job, so a dependent job that lists that job under needs reads them as needs.<job>.outputs.<name>.
Why C is wrong: Values written to GITHUB_ENV are scoped to the job that writes them and never cross into other jobs, so the env context holds nothing for deploy here.
Why D is wrong: There is no jobs context available to expressions at run time, so the caller cannot address another job's outputs this way and the reference is invalid.