What is the GitHub Actions 'jobs.<job_id>.needs' configuration and how does it affect job execution?
Select an answer to reveal the explanation.
Short Explanation and Infographic
needs creates the execution graph for your workflow. jobs: deploy: needs: [build, test] means deploy won't start until both build and test jobs succeed. Without needs, all jobs run in parallel from the start — needs gives you sequential dependencies.
Full explanation below image
![Educational infographic showing GitHub Actions job dependency DAG. Display workflow with 4 jobs: build (no needs, runs first), test-unit and test-integration (both need: build, run in parallel after build), deploy (needs: [test-unit, test-integration], runs after both tests pass). Show visual DAG: build → fork to test-unit and test-integration in parallel → merge → deploy. Show failure behavior: test-unit fails → deploy skipped. Show always() override for cleanup job. Blue dependency graph with parallel and sequential execution. 1024x768 pixels.](/media/github/gh-100/GH-100-q190-infographic.webp)
Full Explanation
The 'jobs.<job_id>.needs' field in GitHub Actions defines explicit dependencies between jobs, creating a directed acyclic graph (DAG) of job execution. Behavior: (1) Jobs listed in 'needs' must complete SUCCESSFULLY before the dependent job runs. (2) Without 'needs', all jobs start in parallel immediately. (3) Multiple dependencies are supported: 'needs: [job-a, job-b]' requires both to complete. (4) Chain dependencies: A→B→C creates a sequential pipeline. (5) Fan-in patterns: multiple jobs can all need a single job. (6) Conditional override: 'if: always()' or 'if: failure()' can allow a job to run even if a needed job failed (e.g., cleanup job). Use 'needs.<job_id>.outputs' to access outputs from dependency jobs. The 'needs' context provides: result (success/failure/skipped/cancelled) and outputs.