English for Tekton Pipelines Developers

Tekton conversations focus on it as a set of low-level, composable building blocks for CI/CD, rather than a full opinionated pipeline product, so the vocabulary emphasizes reuse, isolation, and how data flows between steps.

Key Vocabulary

Task — the smallest reusable unit in Tekton, defining one or more steps that run in sequence inside a single pod, typically doing one job like building an image or running tests. “Keep the build and the push as separate steps within one task, but don’t fold the deploy step in too — deploy belongs in its own task so it can be reused independently.”

Pipeline — a defined sequence of tasks, with explicit ordering and dependencies, that Tekton runs as a Kubernetes-native workflow. “This pipeline runs lint, test, and build as three separate tasks — if we need a different order for a hotfix pipeline, we can reuse the same tasks in a new arrangement.”

Workspace — a shared storage volume that tasks within a pipeline can read from and write to, used to pass files (like build artifacts or source checkouts) between otherwise isolated task pods. “The test task can’t see files the build task produced because they’re not sharing a workspace — mount the same workspace in both so the build output is actually available.”

PipelineRun / TaskRun — the actual execution instance of a pipeline or task definition, holding the specific parameters, status, and logs for one run, distinct from the reusable definition itself. “Don’t debug the pipeline definition — look at the specific PipelineRun that failed, since the actual parameter values and logs live there, not in the template.”

Trigger — Tekton’s mechanism for automatically starting a PipelineRun in response to an external event, typically a webhook from a source control system. “Set up a trigger on pull request events instead of requiring someone to manually kick off the pipeline every time — that manual step is the reason pipelines get skipped.”

Common Phrases

• “Should this be its own task, or does it belong as a step within an existing one?”
• “Are these tasks sharing a workspace, or is that why one can’t see the other’s output?”
• “Should we look at the pipeline definition, or the specific PipelineRun that actually failed?”
• “Is there a trigger configured for this, or does someone have to kick it off manually?”

Example Sentences

Reviewing a pipeline design: “Pulling the deploy step out into its own task means the hotfix pipeline can reuse build and test without also being forced to redefine deploy from scratch.”

Debugging a missing file error: “The test task is failing because it can’t find the built binary — check whether it’s mounting the same workspace as the build task, since that’s how output gets shared between them.”

Discussing automation gaps: “We keep forgetting to run the pipeline before merging — add a trigger on pull request events so it starts automatically instead of relying on someone remembering.”

Professional Tips

• Keep tasks narrowly scoped and reusable — a task that only builds is far more useful across pipelines than one that builds, tests, and deploys together.
• Diagnose “file not found” errors between tasks by checking workspace mounts first — it’s the most common cause of that specific failure.
• When debugging, always look at the specific PipelineRun, not the pipeline template — the actual parameter values and logs only exist on the run itself.
• Recommend a trigger for any pipeline still started manually — manual invocation is a reliable predictor of skipped runs before merges.

Practice Exercise

1. Explain to a teammate why deploy logic should be its own task rather than a step bundled with build.
2. Describe why two tasks in the same pipeline might fail to share files, and how a workspace fixes it.
3. Write a sentence proposing a trigger for a pipeline that currently requires manual invocation.