In a GitHub Actions workflow, what does a job's needs: key change about execution?

## Default: everything at once The `jobs:` map in a GitHub Actions workflow is a *map*, not a script. When a run starts, every job with no `needs:` key is dispatched immediately and they execute concurrently on separate runners, each with its own fresh filesystem. Their order in the YAML file is decoration; two jobs written one after another have no relationship at all. That default is the point: the whole reason CI on GitHub Actions is fast or slow is how much of the work you allowed to happen simultaneously. ## `needs:` adds edges ``` jobs: lint: { runs-on: ubuntu-latest, steps: [...] } test: { runs-on: ubuntu-latest, steps: [...] } package: needs: [lint, test] runs-on: ubuntu-latest steps: [...] ``` `needs:` takes a single job id or a list of them. The named jobs must exist in the *same* workflow file. The resulting edges must form a directed acyclic graph — a cycle (A needs B, B needs A) makes the workflow invalid and it will not run. The scheduler is transitive-aware: if `deploy` needs `package` and `package` needs `test`, `deploy` waits for the whole chain. You do not repeat transitive dependencies, and doing so adds nothing. ## What happens when a dependency does not succeed This is the part interviews probe. The implicit condition on a job with `needs:` is that **all** of its dependencies succeeded. If any one fails, the dependent job's status becomes `skipped` — it is not "failed", it never starts, and its steps never run. A skipped dependency propagates the same way: a job downstream of a skipped job is itself skipped by default. To change that you write an explicit condition: - `if: always()` — run no matter what, including when the run is being cancelled. - `if: !cancelled()` — run after success or failure of dependencies, but let cancellation stop it. GitHub's documentation recommends this over `always()` for long tasks, because `always()` keeps work running after a cancellation is requested. - `if: failure()` — run only when something the job depends on failed. Useful for a notify-on-broken-build job. A subtlety worth stating out loud: adding any `if:` that evaluates to true removes the automatic success gate, so a job with `if: always()` and `needs: [test]` runs *after* `test` regardless of whether `test` passed. If you want it to run only when specific dependencies behaved a certain way, inspect their results explicitly. ## Reading dependency state The `needs` context exposes each dependency: - `needs.<job_id>.result` — one of `success`, `failure`, `cancelled`, `skipped`. - `needs.<job_id>.outputs.<name>` — values the dependency published through its own `outputs:` map. So a summary job can say: ``` if: always() steps: - run: exit 1 if: needs.test.result != 'success' ``` This pattern — one always-running gate job that inspects `needs.*.result` — is how teams get a single stable job name for a required check while the jobs underneath it change shape. ## What `needs:` does *not* give you It does not share a filesystem. Each job gets its own runner and its own empty workspace, so a file built by `test` is invisible to `package` unless you upload it as an artifact and download it, or the job rebuilds it. `needs:` moves *ordering and small values*, not gigabytes of build output. It also does not reduce cost by itself. Serialising jobs makes the run longer while consuming the same total runner minutes; it is worth doing only when there is a genuine dependency, or when you want to avoid spending minutes on a package/deploy job that a failed test has already invalidated. ## Designing the graph The practical shape most pipelines converge on is a diamond: a cheap fan-out of independent checks (lint, unit tests, a matrix of versions), a fan-in job that packages or aggregates, and a deploy job gated behind it. The critical path — the longest chain of `needs:` edges plus each job's own duration — is the wall-clock time of your pipeline, and shortening it is almost always a matter of deleting an unnecessary edge rather than making a single job faster.