The Building Block: Task
The smallest configurable unit in Tekton is the Task. Think of a Task like a recipe card: it describes what to do and what ingredients you need, but it doesn't actually cook anything by itself.
Technically, a Task defines a sequence of Steps. Each Step specifies a container image and a command to run. All Steps within a single Task execute inside the same Pod, which has two important implications:
- Shared network: Steps can communicate over
localhost. - Shared filesystem: Steps can pass files to each other via the
/workspacedirectory mounted on the Pod.
A Task can also declare Parameters (inputs that customize behavior, like a branch name) and Results (small string outputs that downstream Tasks can consume, like a built image digest). A Task resource names itself, declares its typed parameters, and lists its steps in order — each one naming a container image and a script to run inside it, for example an install-deps step running npm ci followed by a run-tests step running npm test, both operating on source checked out into the shared /workspace directory.
The Execution: TaskRun
A Task is a definition — like a class in object-oriented programming. To actually execute it, you create a TaskRun, which is an instance of that Task. When you apply a TaskRun to your cluster, the Tekton controller sees it, creates a Pod with one container per Step, and runs them in sequence. A TaskRun references the Task by name and supplies concrete values for its parameters — for example, a specific application name — under a generateName rather than a fixed name.
The generateName field tells Kubernetes to append a random suffix, ensuring each run gets a unique name — critical for auditability.
Key nuance: Steps within a Task run sequentially by default. If Step 2 fails, Step 3 does not run, and the TaskRun is marked Failed. There is no built-in retry at the Step level — retries are configured at the TaskRun or PipelineRun level.