Pipelines & the DAG

A namespaced object (tekton.dev/v1) listing pipeline tasks, their ordering, and the params and workspaces they share.

It is a template, like a Task: it runs nothing until a PipelineRun points at it. Ordering is declared as data (edges), not as a script, which is what lets Tekton run independent work in parallel.

One execution of a Pipeline with concrete params and workspace bindings. It owns one TaskRun per pipeline task that runs.

It is both the request and the record. The controller reconciles it repeatedly, creating TaskRuns and summarizing their outcomes in a single Succeeded condition.

An entry in spec.tasks: a name plus a taskRef or taskSpec, and optionally runAfter, params, workspaces, when, retries and timeout.

The pipeline task name, not the Task name, is the node in the graph. The same Task can appear many times under different names, and $(tasks.<name>.results.x) refers to that name.

An explicit edge: this task starts only after the listed tasks have finished successfully.

Use it for ordering with no data flow, such as tests after a clone that only shares a workspace. Without it, tasks with no edges between them start at the same time.

Referencing $(tasks.X.results.Y) in a task's params or when expressions makes it depend on X, with no runAfter needed.

Data dependencies order themselves. Sharing a workspace, though, does NOT create an edge: two tasks that write and read the same volume race unless you add runAfter.

The graph of pipeline tasks and their edges, built when the run starts.

Edges only point forward, so there is always an order in which every task's parents finish first. The controller walks this graph on every reconcile to find what is ready to run.

One task with several children that become ready together, e.g. lint, unit-test and e2e all after clone.

This is where Pipelines get their speed: independent children run as parallel Pods. The cost is cluster capacity, since every branch is a Pod with its own resource requests.

One task that runs after several parents, e.g. build after lint and unit-test.

A fan-in task waits for its slowest parent, so a single slow branch holds up everything downstream of the join.

The chain of dependent tasks with the largest total duration. With unlimited capacity it equals the PipelineRun's wall-clock time.

Making a task faster only helps if it is on the critical path. Speeding up anything else just gives it more slack.

Validation that rejects a Pipeline whose edges form a loop, and also catches runAfter pointing at a task that doesn't exist.

A cycle has no valid order: every task in it waits on another. The admission webhook rejects it on kubectl apply. A Pipeline that arrives through a resolver fails the PipelineRun instead (PipelineValidationFailed), before any TaskRun is created.

Once any task fails, the PipelineRun is stopping: running TaskRuns are allowed to finish, but no new ones are created.

A failure doesn't kill siblings that are already running, but branches that haven't started never will, even ones that don't depend on the failed task. Only finally tasks still run.

The list of pipeline tasks that never got a TaskRun, each with a reason: PipelineRun was stopping, When Expressions evaluated to false, Results were missing, Parent Tasks were skipped, or a timeout.

A skipped task has no TaskRun to inspect, so this list is the only place that explains why it didn't run.

The list of child objects (TaskRuns, CustomRuns, child PipelineRuns) the PipelineRun created, with each one's pipelineTaskName.

It is the index from graph node to real object. The full child statuses live on the children themselves, which keeps the PipelineRun object small.

Child TaskRuns are named after the run and the pipeline task, labelled tekton.dev/pipelineRun and tekton.dev/pipelineTask, and owned by the PipelineRun.

The owner reference means deleting the PipelineRun garbage-collects its TaskRuns and Pods. The labels let you select every TaskRun of a run with kubectl get tr -l tekton.dev/pipelineRun=….

The Succeeded condition reasons: Running, PipelineRunStopping, Succeeded, Completed (succeeded with some tasks skipped), Failed, PipelineRunTimeout, Cancelled, PipelineValidationFailed…

As with TaskRuns, status True/False/Unknown says whether it finished, and the reason plus a message like "Tasks Completed: 4 (Failed: 1, Cancelled 0), Skipped: 2" says how.

Deadlines on the whole PipelineRun, on its DAG tasks, and on its finally tasks. timeouts.pipeline defaults to 60 minutes.

When timeouts.pipeline expires, running TaskRuns are cancelled, unstarted tasks are skipped, and the run ends with PipelineRunTimeout. The Control flow chapter covers splitting the budget between tasks and finally.

Tekton creates every ready TaskRun immediately and has no per-pipeline concurrency limit. Throughput is bounded by namespace ResourceQuota and node capacity.

When a quota refuses a Pod, the TaskRun waits as Unknown/ExceededResourceQuota and the controller retries. A wide fan-out under a tight quota runs in waves. That is safe but slower, and the waiting counts against timeouts.

A PipelineRun pointing at a Pipeline by name or through a resolver (git, bundles, hub, cluster).

It lets many runs share one reviewed definition. The resolved spec is copied into status.pipelineSpec, so later edits to the Pipeline don't change a run in progress.

A PipelineRun that carries its whole Pipeline definition.

Common for generated runs (Triggers templates, Pipelines-as-Code). The trade-off is the same as taskSpec: nothing to install, nothing to share.

An alpha feature (TEP-0056) where a pipeline task embeds a pipelineSpec, so the controller creates a child PipelineRun.

It lets you compose whole sub-pipelines (e.g. a security stage) as one node in a parent graph. It is alpha and only partly implemented, so check your release before relying on it.

A free-text label on a Pipeline or a pipeline task, shown by tkn and the Dashboard.

Task names must be DNS-label-safe and stay stable because results refer to them. displayName lets humans read "Build the binary" without renaming the node.