Triggers: Automating Pipeline Execution

The Missing Piece

Everything covered so far requires you to manually apply a PipelineRun YAML to start a build. That's useful for testing, but a real CI/CD system must react automatically to events — a developer pushes code, a pull request is opened, a container image is updated.

Tekton Triggers is a separate component (installed alongside Tekton Pipelines) that bridges external events to pipeline executions. It has three core objects:

1. EventListener

An EventListener is a long-running Pod that exposes an HTTP endpoint. You configure your Git provider (GitHub, GitLab, Bitbucket) to send webhook POST requests to this endpoint whenever an event occurs (push, PR, tag). It declares one or more named triggers, each pairing a TriggerBinding with a TriggerTemplate.

2. TriggerBinding

A TriggerBinding extracts specific fields from the incoming webhook JSON payload and maps them to named variables. GitHub's push webhook, for example, sends a large JSON blob — the TriggerBinding picks out just what you need, such as the repository's clone URL, the commit SHA the push landed on, and the ref that was pushed.

3. TriggerTemplate

A TriggerTemplate is a blueprint for the Kubernetes objects to create when an event fires. It uses the variables extracted by the TriggerBinding to populate a PipelineRun template — referencing the target Pipeline, filling in the extracted repo URL and revision as parameters, and binding the same shared workspace used elsewhere in the pipeline.

The Full Flow

When a developer pushes code to GitHub:

1. GitHub sends a POST request to the EventListener Service URL.
2. The EventListener matches the request to a Trigger.
3. The TriggerBinding extracts clone_url and after (commit SHA) from the payload.
4. The TriggerTemplate creates a new PipelineRun object with those values.
5. The Tekton controller sees the new PipelineRun and starts executing the pipeline.

The entire system is event-driven and stateless — no polling, no persistent build queue.