Skip to main content
RunBook Academy

Git, CI/CD & GitOpsXLVII · Pipeline DependenciesFoundations

The pipeline as a graph — why DAG, not stages, is the right mental model

Intermediate⏱ ~20 mingit

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

Not yet marked complete on this device.

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

  1. Draw the DAG before merging.
  2. File order is irrelevant; the DAG is the execution order.
  3. Review needs: for every job.
  4. 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

  1. 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?

  2. Q2. In a pipeline DAG, every missing edge between two jobs is an opportunity for them to run in parallel.

  3. Q3. Name the two elements of a pipeline DAG and identify which is the ordering guarantee.

  4. 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.