Tekton Pipelines — Dependencies#

Module info#

• Module: github.com/tektoncd/pipeline
• Go version: go 1.25.7
• Direct dependencies: 47 (non-indirect entries across all require blocks)
• Indirect dependencies: ~167 (marked // indirect in go.mod); go.sum has 1,747 lines (~873 module/version pairs total)

Dependency categories#

Core infrastructure / Kubernetes#

The largest and most foundational category — everything here is either a hard Kubernetes requirement or the Knative reconciler framework that drives the controllers.

knative.dev/pkg is not a simple utility — it is the architectural skeleton. The reconciler loop, leader election, webhook registration, log configuration, and controller wiring all come from this dependency. Removing it would require rewriting the entire operator framework.

Observability#

• go.uber.org/zap v1.27.1 — structured, leveled logging; bootstrapped through knative.dev/pkg’s log setup
• go.opentelemetry.io/otel + otel/sdk + otel/trace + otel/metric + otel/sdk/metric + otel/exporters/otlp/otlptrace/otlptracehttp — full OpenTelemetry distributed tracing and metrics stack with OTLP HTTP export; an unusually comprehensive OTel commitment for an operator
• github.com/prometheus/common — Prometheus metric utilities (used alongside OTel’s Prometheus exporter)

Supply chain security (Sigstore + SPIFFE/SPIRE)#

This is the category most distinctive to Tekton relative to other operators in the analysis set.

All four major cloud KMS backends are direct deps, reflecting Tekton’s policy of supporting multi-cloud artifact signing without making any single cloud mandatory. The SPIFFE/SPIRE integration provides pod-level workload identity without Kubernetes service account tokens — an uncommon, advanced security posture.

Runtime / Expression engine#

• github.com/google/cel-go v0.27.0 — Google Common Expression Language; used for evaluating conditions in Pipelines (when expressions, result propagation conditions) and parameter value expressions at runtime. CEL provides safe, sandboxed evaluation without requiring a scripting runtime.
• github.com/cloudevents/sdk-go/v2 v2.16.2 — CloudEvents SDK; Tekton emits CloudEvents for pipeline/task run lifecycle events, enabling integration with event-driven platforms (Knative Eventing, Triggermesh, etc.)

Container registry#

• github.com/google/go-containerregistry v0.21.3 — OCI registry client used to resolve image digests, push/pull Tekton artifacts (bundles), and interact with OCI-stored pipeline definitions
• github.com/google/go-containerregistry/pkg/authn/k8schain — Kubernetes-aware auth chain (reads imagePullSecrets) for registry access
• github.com/goccy/kpoward v0.1.0 — Kubernetes port-forwarding client; used for accessing internal registry endpoints (e.g., in-cluster registry) during resolution

SCM / Source control management#

• github.com/jenkins-x/go-scm v1.15.17 — generic SCM abstraction layer supporting GitHub, GitLab, Bitbucket, Gitea; used by the Git resolver to fetch pipeline definitions from source repositories
• code.gitea.io/sdk/gitea v0.21.0 — Gitea-specific client (direct dep because go-scm’s Gitea support requires it explicitly)

Networking / gRPC#

• google.golang.org/grpc v1.79.3 — gRPC; used for SPIFFE/SPIRE workload attestation calls and OpenTelemetry OTLP gRPC export
• google.golang.org/protobuf v1.36.11 — protobuf serialization; used with SPIRE API SDK and OTel proto formats

Utility#

Testing#

• github.com/google/go-cmp — primary comparison library for test assertions (testify is only an indirect dep, suggesting it comes transitively through knative or other deps rather than being used directly in Tekton’s own tests)
• No gomock or ginkgo as direct deps; testing appears to rely on stdlib + go-cmp

Stdlib reliance#

Tekton makes heavy use of the standard library. The reconciler files sampled show consistent use of:

• context — ubiquitous; every reconcile function receives a context
• fmt, errors — error construction and wrapping
• time — timeout and duration tracking
• strings — string manipulation
• encoding/json — JSON marshaling/unmarshaling of Kubernetes objects and pipeline results
• sort — deterministic ordering (important for test reproducibility)
• sync — mutex and WaitGroup for concurrent state (though often replaced by golang.org/x/sync/errgroup)

The project is not stdlib-first in the way a small utility library might be. The Kubernetes and Knative layers pull in large dependency trees. Within those constraints, individual packages are reasonably lean and rely on stdlib for logic-level work.

Shared dependencies#

Dependencies shared with many other projects in the analysis set (creates connection points for cross-project chapters):

• k8s.io/client-go — shared with all Kubernetes controllers/operators in the set
• go.uber.org/zap — shared with Knative-based and many cloud-native Go projects
• google.golang.org/grpc — shared with etcd, Prometheus, and any project using gRPC
• google.golang.org/protobuf — shared broadly wherever gRPC or proto is used
• github.com/google/go-cmp — nearly universal in modern Go test code
• github.com/prometheus/common — shared with Prometheus-adjacent projects
• golang.org/x/sync — shared almost universally
• golang.org/x/crypto — common wherever TLS or key material is handled
• github.com/sigstore/sigstore — emerging shared dep in supply-chain-aware projects (connects to sigstore ecosystem analysis)

Vendoring#

Yes, vendor directory is present. This is consistent with Tekton’s Kubernetes heritage — k8s.io/* projects vendor dependencies to ensure reproducible builds in CI environments, avoid network dependencies during compilation, and enable easier auditing of transitive code. The vendor directory is populated via go mod vendor and committed to the repository.

Notable dependency decisions#

1. Knative as the operator skeleton, not controller-runtime. Most Kubernetes operators in 2024 choose sigs.k8s.io/controller-runtime. Tekton chose knative.dev/pkg because it was originally part of Knative and the migration cost has never justified switching. This makes Tekton structurally divergent from most modern operators — Knative’s reconciler pattern, webhook wiring, and logging conventions permeate the codebase.

2. Four KMS backends as direct deps. Rather than making cloud-provider KMS support optional (via build tags or plugin interfaces), all four backends (AWS, Azure, GCP, HashiCorp Vault) are direct dependencies. This means every build of Tekton carries the full AWS SDK, Azure SDK, and GCP SDK even if only one KMS is configured. The tradeoff favors operational simplicity (single binary) over binary size.

3. CEL for expression evaluation over Go templates or scripting. The use of cel-go for when conditions and parameter expressions is a principled choice: CEL is safe (no side effects, deterministic, no I/O), fast, and auditable — important properties for a CI/CD system that executes user-supplied expressions in a privileged cluster context.

4. Legacy pkg/errors retained alongside stdlib errors. The presence of github.com/pkg/errors as a direct dep (rather than indirect) suggests some code paths still use errors.Wrap / errors.Cause. This is a minor tech-debt signal — the Go ecosystem moved to fmt.Errorf %w and errors.Is/As in Go 1.13, and pkg/errors is now largely superseded.

5. SPIFFE/SPIRE as direct deps (not optional). Workload identity via SPIFFE is compiled into the main binary, not an optional plugin. This reflects Tekton’s commitment to supply chain security (SLSA compliance) as a core feature, not an afterthought — unusual for operator-style projects where security is often delegated to infrastructure.