Why can you NOT use the 'jobs' context inside a job-level 'if:' condition to inspect another job that already finished?
Select an answer to reveal the explanation.
Short Explanation and Infographic
For dependent jobs, declare needs and read needs.<id>.result or outputs. The jobs context is not the tool for gating one job on another inside the same workflow's if: condition.
Full explanation below image
Full Explanation
When job B must condition on job A, list A under B's needs: and use needs.A.result or needs.A.outputs.* in B's if:. The jobs context is used in specific situations such as mapping outputs from a reusable workflow call (jobs.<job_id>.outputs) in the caller after a uses: reusable job. It is not a general-purpose graph of all jobs available during job-level if evaluation the way needs is. jobs is not limited to composite actions or self-hosted runners. Job-level if: conditions can use many contexts (github, needs, vars, and more) but you should pick the correct context for the dependency model. Exam questions often test whether you pick needs versus jobs versus steps correctly by scope.