What are Steps in a Tekton Task and how do they share data?

Imagine steps as workers sitting at the same desk in an office. Each worker (step) does their job one after the other, and because they share the same desk (pod filesystem), the first worker can leave documents (files) for the next worker to pick up. The desk drawers (workspaces) are shared storage, and the sticky notes (results) are small messages passed along.

In Tekton, a step is the smallest unit of execution. Each step is defined inside a Task spec and specifies a container image, a script or command to run, and optionally resource limits, environment variables, and volume mounts. Steps within a Task always execute sequentially in the order they are defined. When the Tekton controller creates a pod for a TaskRun, each step becomes a container within that pod. Tekton uses an internal entrypoint mechanism to ensure that step two does not start until step one has completed successfully. For example, in the payments-api build task, the first step clones the repository, the second step compiles the code, and the third step runs tests. Each step uses a different container image suited to its purpose: a git image for cloning, a golang image for compiling, and a testing image for running tests.

The primary mechanism for sharing data between steps is the shared filesystem within the pod. By default, Tekton mounts an emptyDir volume at a well-known path, and workspaces provide additional shared mount points. When the inventory-sync team defines a workspace called source, all steps in the Task can read from and write to $(workspaces.source.path). The first step clones the Git repository into this path, and subsequent steps can access the source code, build artifacts, and test results written there. Because all steps run in the same pod, this filesystem sharing is fast and does not require any network transfer. Additionally, Tekton provides a special /tekton/results directory where steps can write small string values (up to 4096 bytes) that become TaskRun results, which can then be referenced by other tasks in a Pipeline.

In production scenarios, teams use steps to decompose complex operations into discrete, debuggable units. The user-auth-service team might have a security scanning task with four steps: download the vulnerability database, scan dependencies, scan the container image, and generate a compliance report. Each step uses a specialized container image, but they all share the same workspace where the scan results accumulate. If the dependency scan step fails, the team can inspect the logs for that specific step without wading through the output of the entire task. The step-level granularity also makes it easy to add retry logic or timeout settings to individual operations.

A common beginner pitfall is trying to share data between steps using environment variables set in one step and read in another. Environment variables are scoped to a single container and do not persist across steps. Instead, you must write values to files in the shared workspace or use Tekton results. Another gotcha is that each step runs as a separate container with its own filesystem root, so a binary installed in step one (say, in /usr/local/bin) is not available in step two if it uses a different container image. The shared workspace is the only reliable mechanism for passing data. Finally, steps cannot run in parallel within a Task. If you need concurrent execution, you must split the work into separate Tasks within a Pipeline.