A reusable workflow called through workflow_call computes a build identifier and must return it to the caller so the caller can reference it as needs.call-build.outputs.build_id. The reusable file already sets a job output. What else must the reusable workflow declare for the value to reach the caller?
on:
workflow_call:
outputs:
build_id:
value: ${{ jobs.compute.outputs.build_id }}- ADeclare an output under on.workflow_call.outputs whose value maps to the job output, because a reusable workflow only returns values that are mapped through its workflow_call outputs block. Correct
- BNothing further, because once a job inside the reusable workflow sets a job output, the caller can read it directly as needs.call-build.outputs.build_id without any on.workflow_call declaration.
- CUpload the build identifier as an artifact in the reusable workflow, because the caller automatically downloads artifacts produced by a called workflow and reads them as job outputs.
- DWrite the build identifier to the GITHUB_ENV file in the reusable workflow, because env values set there are inherited by the calling workflow and exposed under the called job's outputs.
Why A is correct: A reusable workflow returns data only through an on.workflow_call.outputs entry whose value references the producing job output, so mapping build_id there lets the caller read needs.call-build.outputs.build_id.
Why B is wrong: Tempting because the job output exists, but a reusable workflow only exposes values the caller can read when they are declared under on.workflow_call.outputs, so the caller would otherwise see nothing.
Why C is wrong: Tempting because artifacts share data, but they are downloaded explicitly and are not surfaced as outputs, so an artifact cannot populate needs.call-build.outputs.build_id for the caller.
Why D is wrong: Tempting because GITHUB_ENV sets values, but those stay inside the job that wrote them and are never inherited by the caller, so they cannot become a reusable workflow output.