Tekton Pipelines — Overview#

Identity#

Purpose#

Tekton Pipelines provides Kubernetes-native CI/CD pipeline primitives as Custom Resource Definitions (CRDs). It solves the problem of defining portable, containerized CI/CD workflows that run on any Kubernetes cluster, treating pipelines as first-class Kubernetes objects (Task, TaskRun, Pipeline, PipelineRun). The primary audience is platform engineers and DevOps teams building cloud-native CI/CD systems on top of Kubernetes.

Significance#

Tekton is a CNCF project and the de facto standard for Kubernetes-native CI/CD. It underpins Red Hat OpenShift Pipelines, Google Cloud Build, and is embedded in multiple commercial CI/CD platforms. Its influence extends beyond direct usage: it defined the vocabulary and patterns (CRD-based pipeline resources, step-as-container, workspace sharing) that shaped the broader cloud-native CI/CD ecosystem. The project has an active community with rigorous API versioning policies (v1alpha1 → v1beta1 → v1 migration history) and conformance testing, signaling institutional maturity.

Key metrics#

  • Go files: 983 (excluding vendor)
  • Top-level directories: cmd, config, docs, examples, hack, internal, optional_config, pkg, tekton, test
  • Direct dependencies: ~46 (across two require blocks in go.mod; excludes indirects)
  • First commit / age: Repository history available from 2026-04-01 in local clone; project originated in 2018 as part of Knative, spun out into CNCF in 2019

Notable characteristics#

  • Knative reconciler framework: Built entirely on knative.dev/pkg, inheriting its reconciler pattern, leader election, logging (zap), metrics, and webhook infrastructure — a strong architectural dependency that shapes almost every controller.
  • Supply chain security as a first-class concern: Integrates SPIRE/SPIFFE (spiffe/go-spiffe/v2, spiffe/spire-api-sdk) for workload identity and Sigstore (sigstore/sigstore) with multi-cloud KMS backends (AWS, GCP, Azure, HashiCorp Vault) for artifact signing and trusted resource verification.
  • Sidecar-based step execution: Pipeline steps run sequentially inside a single Pod using an injected entrypoint binary (cmd/entrypoint) that gates execution via file-based signaling — a non-obvious architectural trick to enforce ordering within Kubernetes Pods.
  • Resolution framework: A pluggable system (pkg/resolution, pkg/remoteresolution) for fetching Task and Pipeline definitions from remote sources (Git, HTTP, OCI registries, cluster), decoupling resource definition from execution.
  • CEL expressions for runtime control: Uses Google’s cel-go library for evaluating conditions and parameter expressions at pipeline runtime, enabling dynamic pipeline behavior without custom controllers.
  • OpenTelemetry native: Full distributed tracing integration via go.opentelemetry.io/otel with OTLP HTTP export, reflecting modern observability expectations for long-running Kubernetes operators.