Tekton Triggers: turning event payloads into Kubernetes resources

A controller that reacts to events by creating resources

Tekton Triggers is a Kubernetes Custom Resource Definition controller that allows you to create Kubernetes resources based on information it extracts from event payloads. That one sentence is the whole mechanism, and it is easier to understand once you separate the two halves. Something in the cluster receives an event, a push to a Git repository or a message on a topic, and the Triggers controller watches for those events, extracts fields from the payload, and uses those fields as variables in a template that describes the resources to create. The resources it creates are typically Tekton PipelineRuns, and once a PipelineRun exists the rest of the Tekton machinery takes over, running the steps you defined. The value of this is that the glue between your source host and your build system stops being a piece of software you have to operate. There is no webhook service to deploy, no secret to rotate for a third party service, and no network rule to maintain, because the trigger runs inside the cluster you already run. The project originates from an implementation of a design document, and the README notes the design was visible to members of the Tekton mailing list.

What it adds to Tekton Pipelines

The background section explains the relationship with the parent project, and it is the reason to choose Triggers rather than wire something together yourself. Tekton is a Kubernetes-native continuous integration and delivery framework that allows you to create containerized, composable and configurable workloads declaratively through Kubernetes CRDs. Pipelines, in other words, describe what should run and how, but they do not describe when to run. Triggers fills that gap, and when integrated with Tekton, Tekton allows you to easily create fully fledged CI/CD systems in which you define all mechanics exclusively using Kubernetes resources. The word exclusively is the important one. A typical CI setup has a build definition in one format, a webhook configuration in another, and a token in a third, and the pieces drift. With Triggers the trigger, the template and the pipeline are all Kubernetes objects, so a cluster administrator can see the whole chain, and the same Git push that starts a build can also be the event that triggers a release pipeline. The docs listed in the README break this down into an overview, a setup guide, a getting started walkthrough and a set of code examples, and the getting started guide walks through an end-to-end image building solution triggered via GitHub's push events.

The Kubernetes version floor moves with each release line

The README is unusually explicit about which Kubernetes version each release of the project expects, and the list is worth reading because it tells you how the floor has moved over time. Starting from the v0.29.x release of Tekton, Kubernetes version 1.28 or later is required. Starting from the v0.27.x release, Kubernetes 1.27 or later. From the v0.26.x release, Kubernetes 1.25 or later. From the v0.25.x release, Kubernetes 1.24 or later, and from the v0.24.x release, Kubernetes 1.24 or later as well. The current line is therefore on 1.28, which for a Kubernetes-native project is a reasonable place to sit, since a controller that uses newer API features is not portable down. The version history also tells you the shape of the release process, since the recent releases are v0.36.4 and v0.36.3 both dated 2026-10-09 along with v0.35.3 on the same day. Three releases in one day across two minor lines is a project shipping maintenance fixes for more than one supported version, which is the norm for a component that other people's clusters depend on. The last push to the repository was on 2026-10-15, and the project is not archived, so the trigger controller is actively maintained.

The dependency set tells you what a trigger has to understand

The go.mod is long, and reading it tells you what a trigger has to parse in order to start a build. The eventing side comes from CloudEvents, with the cloudevents/sdk-go/v2 dependency at 2.16.2, and the Knative packages for eventing and serving are there, along with knative.dev/pkg, which is the shared Knative library that carries the webhook and reconciler machinery. The Kubernetes client libraries are pinned at the 0.35 and 0.36 lines, and the controller uses Tekton Pipeline itself at v1.15.0, so the Triggers and Pipelines versions are chosen together. The expression language for extracting fields from a payload is cel-go at 0.30.0, and the companion cel.dev/expr package appears as an indirect dependency, which is the pattern for a language that has been split out of its original repository. Other dependencies show the range of event sources: go-github/v31 for GitHub events, GoogleCloudPlatform cloud-builders gcs-fetcher, and the CloudEvents SDK. A cron dependency, robfig/cron/v3, is present as well, and the observability side uses the OpenTelemetry packages, zap for logging, logrus, the Prometheus client model and common packages, and grpc. The Go version line is 1.26.4, and the module vendors its dependencies, with the Makefile building with -mod=vendor.

Cross-platform builds and the release machinery

The Makefile shows how the project is built and released, and it is a good example of a Kubernetes controller's packaging needs. The build target compiles each command under cmd/ into a binary, and a cross target builds for five platforms in one go.

cross: amd64 arm arm64 s390x ppc64le ## build cross platform binaries

The individual platform rules set GOOS and GOARCH and build every command with the vendored modules.

	GOOS=linux GOARCH=amd64 go build -mod=vendor $(LDFLAGS) ./cmd/...

	GOOS=linux GOARCH=arm64 go build -mod=vendor $(LDFLAGS) ./cmd/...

Building for s390x and ppc64le alongside amd64 and arm is the clearest signal of the audience, since those are the architectures that show up in enterprise Kubernetes clusters and on the IBM and POWER machines those clusters often run on. The release path uses ko, the Google tool that builds and pushes container images straight from a Go source tree without a Dockerfile, configured through the .ko.yaml file at the top of the repository, and the apply target is described in the Makefile as ko apply. The version string is derived from git describe with a fallback to a .version file and then to v0, and the test timeout is five minutes per package with a twenty minute end-to-end timeout. The repository also carries a .golangci.yml for linting, a .pre-commit-config.yaml, a .yamllint configuration, an .errcheck.txt file for the error checking allowlist, and a .codecov.yaml, so the code quality tooling is configured rather than improvised.

The examples show RBAC as part of the design

The examples directory is small and instructive. There is a README.md, an example-pipeline.yaml, an rbac.yaml, and versioned directories for v1alpha1 and v1beta1, so the examples exist at more than one API version, which is the usual Kubernetes pattern for a project that has graduated an alpha API and keeps both around. The presence of a dedicated rbac.yaml is the part worth pausing on. A controller that creates resources on your behalf needs permission to create those resources, and in a cluster where the pipeline runs arbitrary user code, over-broad permissions are how a build pipeline becomes a privilege escalation path. The example therefore ships the role alongside the pipeline rather than leaving the reader to work out what to grant. The configuration lives in a config/ directory at the top level, which for a Kubernetes project is the conventional place for the CRD definitions and the controller's own deployment manifests, and the .tekton/ directory holds the project's own pipeline definitions, so the project builds itself with the tool it provides. The other top level directories follow the standard Go and Kubernetes layout, with cmd/ for the entry points, pkg/ for the implementation, test/ and hack/ for testing and developer scripts, and tools/ for tool dependencies.

Where Tekton Triggers is the wrong tool

The limits come from the same place as the strengths. Triggers creates Kubernetes resources. If what you want is to run a build on a machine that is not in Kubernetes, this is the wrong project, and a general CI server is the right one. If you want a hosted CI product with a web interface, a build matrix, artefact storage and a badge, the trigger mechanism gives you none of that, because the interface between your source host and the cluster is a Kubernetes object rather than a user experience. There is also a coupling to consider. A trigger controller sits in the path of every event, and if it is misconfigured it can create the wrong PipelineRun, run the wrong ref, or fail silently in a way that looks like a pipeline that never started. The RBAC example is there precisely because that failure mode has a security dimension. The second limitation is version matching. Triggers and Pipelines are separate projects with separate release lines, and the go.mod pins a specific Pipelines version, so a cluster running an older Pipelines needs a matching Triggers, and the frequent point releases across several minor lines make it easy to end up with a mismatch if you do not manage the pair deliberately. The last one is scope of the event model. The dependencies show support for CloudEvents, Knative eventing, GitHub events and cron, and while that is broad, a source host with an unusual event format means you are back to writing an adapter, at which point the question is whether the adapter belongs in the cluster.

Editorial conclusion

Adopt Tekton Triggers if you run Tekton Pipelines in Kubernetes and want build and deploy pipelines to start from a push, a pull request or a cloud event without a separate webhook service, and you can live with a Kubernetes version of 1.28 or later. Skip it if you want a general CI server, since the trigger mechanism only creates Kubernetes resources, or if you need a stable release channel, since the project ships frequent point releases across several minor lines at once. Verify first which Triggers version matches your installed Pipelines version, that your cluster meets the documented Kubernetes floor, and that the RBAC you grant the controller is limited to what your templates create.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. tektoncd/triggers on GitHub