Git, CI/CD & GitOpsXLVII · Pipeline DependenciesFoundations
The pipeline as a graph — why DAG, not stages, is the right mental model
What you'll learn
- Identify the nodes and edges of a pipeline DAG from a workflow file
- Distinguish the DAG model from the stages model
- Predict which jobs run in parallel by reading the graph, not the file order
Prerequisites
Verified against Git 2.55.x teaching target; 2.40+ minimum · GitHub Actions continuous service; Aug 2026 documentation baseline · Argo CD v3.5.x teaching target; v3.0+ minimum · Flux v2.9.x · Sigstore Cosign v3.1.x · SLSA v1.2 · OCI Distribution Specification v1.1 · Git LFS v3.7.1 · Kubernetes (cross-course target) 1.36.x
A pipeline is a directed acyclic graph. Nodes are jobs; edges are dependencies. The graph is what the scheduler walks. The “stages” model is one particular graph: a totally ordered chain. The DAG model is the more general one, and the model every modern CI vendor implements.
Nodes and edges
Nodes are jobs. Edges are dependencies: an edge from A to B means “B cannot start until A has completed”. The edge is the ordering guarantee; the absence of an edge is the opportunity for parallelism.
flowchart LR
L["lint"] --> T["test"]
L --> S["scan"]
T --> P["package"]
S --> P
File order is not execution order; the DAG is the contract.
DAG versus stages
The stages model forces every job in stage N to wait for every job in stage N-1: convenient when dependencies are regular, painful when they are not. The DAG model removes the constraint: a job declares exactly the predecessors it needs. Every edge is deliberate; every missing edge is deliberate too.
Reading the DAG from a workflow file
The graph is implicit in needs: clauses. Reading
every job’s needs: list yields (job, predecessors)
pairs; plotting them yields the DAG.
grep -E '^ [a-z-]+:$|needs:' .github/workflows/ci.yml
A reviewer who reads the DAG sees the actual execution order.
What the scheduler does
The scheduler builds the DAG in memory and maintains a “ready” set of jobs whose incoming edges are all satisfied. It starts every ready job as soon as a runner is available. The algorithm is topological: a job never starts before its predecessors.
Wall-clock cost is the critical path, not the sum of job durations.
Production discipline
- Draw the DAG before merging.
- File order is irrelevant; the DAG is the execution order.
- Review
needs:for every job. - Watch for unintended fan-in.
Cross-course references
- Ansible for Production Sysadmins - Part XXXVII (RepoArch) applies the same DAG concept to AWX workflows.
- Linux for Production Sysadmins - Part XXX uses DAG
concepts for systemd
After=.
Quiz
Knowledge check · 4 questions
Q1. Workflow lists deploy, package, build, scan, unit, integration. Edges: package->deploy, build->package, unit->package, integration->package, build->scan. In what order do jobs start?
Q2. In a pipeline DAG, every missing edge between two jobs is an opportunity for them to run in parallel.
Q3. Name the two elements of a pipeline DAG and identify which is the ordering guarantee.
Q4. Diagnose why a pipeline takes 18 minutes when the critical path should be 4 minutes, and recommend a DAG redesign.
Team H: build (2), unit (1), integration (8), scan (3), deploy (2 min). Total: 18 min wall-clock.
Passing score: 75%. Answers are checked in this browser.