Tekton Pipeline Builder

A Tekton Task is the smallest unit of work — it defines a sequence of Steps (container runs) that perform a single CI/CD action like cloning a repo, building an image, or running tests. Each Step runs in its own container within a shared Pod. A Pipeline is a directed acyclic graph (DAG) of Tasks — it orchestrates multiple Tasks with dependencies (runAfter), shared workspaces, and params. Tasks can be reused across many Pipelines, making them composable building blocks. ClusterTasks are Tasks available cluster-wide without a namespace, while regular Tasks are namespace-scoped.

runAfter specifies which Tasks must complete successfully before a Task can start — it defines the DAG execution order. Tasks without runAfter start in parallel immediately. Tasks with the same runAfter set also run in parallel once their dependency completes. Use runAfter to model your pipeline's dependency graph: clone → build → test → push → deploy. Be careful not to create cycles. If you need a Task to start regardless of whether a previous Task succeeded or failed, don't use runAfter — instead use a Finally task (defined in the pipeline's finally: section), which runs at the end no matter what.

Workspaces are shared storage volumes that Tasks use to pass files between each other. The Pipeline declares which workspaces it needs, and each Task declares which workspaces it uses. When creating a PipelineRun, you bind each Pipeline workspace to a concrete volume — usually a PersistentVolumeClaim (PVC). For example, a git-clone Task writes the source to a 'source' workspace, and a buildah Task reads from that same 'source' workspace. Without workspaces, Tasks run in isolated Pods with no shared filesystem. Workspaces can also be Secrets, ConfigMaps, or emptyDir (ephemeral, within the same TaskRun).

A ClusterTask is a Task that is available cluster-wide without being tied to a specific namespace — useful for shared CI/CD primitives like git-clone, buildah, or kaniko that every team uses. However, ClusterTask is deprecated as of Tekton Pipelines v0.53+ and will be removed in a future version. The recommended replacement is to use a namespace-scoped Task with a resolver reference (like the Hub resolver or Cluster resolver). For production setups, prefer using Tekton Hub tasks via resolvers: taskRef: { resolver: hub, params: [{name: catalog, value: tekton}, {name: name, value: git-clone}] }.

Manual runs use 'kubectl create -f pipelinerun.yaml' or 'tkn pipeline start <name>'. For automatic triggering, use Tekton Triggers — install the Triggers component, then create an EventListener (an HTTP server), TriggerTemplate (creates PipelineRuns from events), and TriggerBinding (extracts data from webhook payloads). Point your GitHub/GitLab webhook at the EventListener URL and it will automatically create PipelineRuns on push or PR events. Tekton Triggers also supports CEL filters to conditionally trigger pipelines based on branch, event type, or any field in the webhook payload.

Tekton runs entirely inside your Kubernetes cluster — it uses Kubernetes CRDs for pipelines, native Pods for task execution, and PVCs for storage. This gives you full control, no vendor lock-in, and the ability to run on any cloud or on-premises. GitHub Actions runs in GitHub's cloud (or self-hosted runners) and is tightly integrated with GitHub — simpler to set up but harder to run in air-gapped environments. Tekton requires more infrastructure investment (cluster, Tekton Operator, Triggers) but is the standard for organizations that want a portable, Kubernetes-native CI/CD solution. Tekton pipelines can also be triggered from GitHub Actions workflows using the Tekton CLI or API.