What Is a Job Dependency? Ordering Jobs in a Pipeline
A job dependency tells the pipeline that one job must complete (usually successfully) before another may start.
Jobs in a pipeline often run in parallel by default, but some have an order: you must build before you test, and test before you deploy. A job dependency expresses that order. By declaring which jobs depend on which, you turn a flat list of jobs into a structured graph the pipeline can schedule correctly.
How dependencies order work
When job B depends on job A, the pipeline holds B until A finishes successfully. Jobs with no dependency between them are free to run at the same time. The set of dependencies defines the whole execution order.
Dependencies create a graph
Stack enough dependencies and you get a directed acyclic graph: nodes are jobs, edges are dependencies. The pipeline runs each job as soon as all its prerequisites are done, maximizing safe parallelism.
A quick example
In GitHub Actions, needs: [build] on a test job makes it wait for build. A deploy job with needs: [test] waits for test. Two independent test jobs with no needs between them run in parallel.
Passing data along a dependency
- Outputs: a job exposes values its dependents read.
- Artifacts: a job uploads files a later job downloads.
- The dependency edge is the channel for both.
Dependencies and speed
Every dependency removes a chance to run in parallel, so a long chain of dependencies is a long pipeline. Declaring only the dependencies you truly need keeps the graph wide and fast.
Key takeaways
- A job dependency forces one job to finish before another starts.
- Dependencies form a graph that defines safe parallel execution order.
- They also carry data forward via job outputs and artifacts.