Tekton makes CI a set of Kubernetes resources
Tekton Pipelines adds Task, TaskRun, Pipeline, and PipelineRun resources to Kubernetes. A Task describes container steps. A Pipeline connects Tasks, and a PipelineRun creates the work on a cluster. That model gives a platform team reusable building blocks without making every repository adopt a vendor's workflow syntax. It also means Kubernetes scheduling, service accounts, namespaces, admission controls, and logs become part of the CI system.
The stable API list contains 4 v1 resources: Task, TaskRun, Pipeline, and PipelineRun. CustomRun and ResolutionRequest remain v1beta1, while older v1beta1 pipeline resources are deprecated. This distinction matters when a team copies an example or enables a feature. Stable fields receive the strongest compatibility promises; alpha fields can change after one release of warning, and beta changes receive a migration period. Tekton rewards teams that check the stability label instead of treating every YAML field alike.
The controller is useful when Kubernetes is already the platform
Tekton fits an internal developer platform that already has cluster identity, image policy, secrets management, and observability. Tasks are containers, so a build can swap tools or run against another cluster without rewriting the controller. Individual Tasks can also run outside a full Pipeline, which makes a shared catalog practical. The Apache-2.0 license leaves room for internal tooling and commercial services around it.
That fit is narrow by design. The current installation guide requires Kubernetes 1.28 or later, kubectl, and cluster-admin privileges. A five-person application team using hosted Git repositories may gain little from owning another controller, webhook, release process, and set of custom resources. Tekton provides execution primitives. It does not provide hosted runners, billing, or a ready-made approval process around your organization.
What happened when we ran it
Our sandbox installed the commit bbc5b44 checkout in 149 seconds and installed 0 packages. The Go build succeeded in 220 seconds. Tests completed in 163 seconds, with 150 passed and 0 failed out of 150. Nothing in those three steps produced a compiler or test error. That is strong evidence that the checked-out source can be worked on in the stated Go environment.
The repository itself had 1,486 files, about 310,231 lines of source, and a 14.2 MB checkout. We found 17 CI workflow files and a tests directory, but no Dockerfile. Those facts describe repository development, not a live Tekton deployment. Our unprivileged 3-CPU, 8 GB container did not create a Kubernetes cluster, install the release manifest, run a PipelineRun, pull private images, or exercise cluster failure recovery.
The one-line install stops before production starts
The documented quick start applies a release manifest with kubectl, then watches the tekton-pipelines namespace until its components report ready. The same page says that route is not intended for production and points operators to the separate Tekton Operator for installation, upgrades, and management. Metrics Server is optional for high-availability cases. Every useful pipeline then brings its own registry, source-control, cloud, and deployment permissions.
The runtime defaults deserve a configuration review. Beta features are enabled by default, while alpha features require flags. The docs say multi-tenant installation is only partially supported. They also document x86 Linux nodes as the supported platform and describe a security-context flag for namespaces using restricted pod security admission. That is workable for a platform group with a cluster baseline. It is poor material for an application team hoping that one manifest settles isolation and policy.
Two open issues expose contract and secret-handling limits
Open issue 9714 tracks secret masking for step stdout and stderr. Its proposal would cover secrets mounted through common environment and volume paths, but the issue also says masking would not make secrets inaccessible to users who can read pod specs. Until that work lands and is verified, pipeline authors must keep credentials out of command output and enforce Kubernetes access carefully. A CI log is often copied farther than the namespace that produced it.
Issue 3497 has remained open around declared Task results. Its example shows that a Task can claim a result and omit it without failing when no downstream step consumes that value; referencing the missing result does cause failure. Teams treating Task definitions as typed interfaces should add their own contract tests. Another open issue, 4364, records that Task references inside Tekton bundles are unsupported while bundles remain alpha. These are specific edges, not reasons to dismiss the stable core.
Current releases show active maintenance and real upgrade work
GitHub recorded 9,045 stars, 555 combined issues and pull requests, and a push on August 26, 2026. The latest release was v1.15.0 LTS, published July 31, 2026. Its notes include fixes for missed resolution events, matrix-count overflow, sidecar result extraction, API conversion, and debug-script permissions. The activity is current, and the combined open count should not be read as 555 confirmed bugs.
Upgrades still demand reading. Tekton publishes a compatibility policy, a deprecation table, migration guides, versioned documentation, and release attestations. That is better than pretending CRDs never change. It also signals the operating bargain: teams get a well-maintained Kubernetes pipeline layer, while they own version selection, feature flags, controller rollout, and Task behavior. If that ownership matches the platform charter, Tekton is an easy project to shortlist. If it does not, use a managed CI service and spend the saved time on the application.