What are Pipelines and PipelineRuns in Tekton?

If a Task is a single workstation on an assembly line, a Pipeline is the entire factory floor layout that defines which workstations operate in which order, which ones can run in parallel, and how parts (data) move between stations. The PipelineRun is the actual production run where raw materials enter and a finished product comes out the other end.

A Tekton Pipeline is a Kubernetes Custom Resource that defines a collection of Tasks arranged in a specific execution order. Each Task within a Pipeline is referenced as a pipeline task (under the tasks array in the spec), and you can define dependencies between tasks using the runAfter field. Tasks without dependencies or runAfter constraints run in parallel by default. For example, the checkout-service team might define a Pipeline with four tasks: clone the source code, then run unit tests and security scanning in parallel (since neither depends on the other), and finally deploy to staging only after both tests and scanning succeed. This creates a DAG execution model where the Tekton controller determines the optimal execution order based on declared dependencies.

Internally, when you create a PipelineRun, the Tekton controller reads the Pipeline definition and creates a TaskRun for each pipeline task. Each TaskRun becomes its own Kubernetes pod, meaning tasks run in separate pods with separate filesystems and network namespaces. Data is shared between tasks through workspaces (backed by PersistentVolumeClaims) and results (small string values passed between tasks). The PipelineRun resource tracks the aggregate status: it is considered successful only if all TaskRuns succeed, and it fails if any required TaskRun fails. The user-auth-service team can inspect a PipelineRun to see which tasks completed, which are running, and which are pending, all through standard kubectl commands or the tkn CLI.

In production, Pipelines enable teams to model complex CI/CD workflows with clear separation of concerns. The order-processing-service team defines their deployment pipeline with stages for building the container image, running integration tests against a test database, scanning the image for vulnerabilities with Trivy, deploying to a staging environment, running smoke tests, and finally promoting to production with a manual approval gate. Each of these stages is a separate Task, and the Pipeline defines how they connect. Workspaces carry the source code and build artifacts through the pipeline, while results pass metadata like the built image digest from the build task to the deploy task.

A critical gotcha for beginners is understanding that tasks in a Pipeline run in separate pods, unlike steps within a Task that share a pod. This means you cannot simply write a file in one task and read it in the next unless they share a workspace backed by a PersistentVolumeClaim. Another common mistake is not setting runAfter correctly, which causes tasks to run in parallel when they should be sequential. Also, PipelineRuns support timeouts at both the pipeline level and individual task level, and beginners often forget to set these, leading to stuck pipelines that consume cluster resources indefinitely when a task hangs.