logo
Alauda DevOps Pipelines Docs
logo
Alauda DevOps Pipelines Docs
Navigation

Overview

Introduction
Architecture
Feature Overview
Lifecycle Policy
Quick Start
Release Notes

Concepts

TektonConfig
TektonPipeline
Install
Upgrade

Configure

Adjusting Optional Configuration Items of Subcomponents
Configuring Resource Quotas for Pipeline Components
Pod Template Configuration Guide
Regular Cleanup of TaskRun and PipelineRun Resources

How To

Deploying tekton-pipelines in a global cluster through TektonConfig

Pipelines

Introduction
Architecture

Concepts

Tasks
TaskRuns
Pipelines
PipelineRuns
StepActions
Resolvers
Workspaces
Pod Templates
Quick Start
permissions

how_to

Adjust Dockerfile for Building Task-Compatible Custom Images

trouble_shooting

Failed to create pod due to config error when using custom images in Tekton

Triggers

Introduction
Architecture

Core Concepts

Core Concepts
EventListener
Trigger
Interceptor
TriggerBinding
TriggerTemplate
Quick Start

How To

Setup EventListener
Use GitLab Event Triggers
Create TriggerTemplate

Troubleshooting

The Pipeline is not automatically triggered
Permission Description

Hub

Introduction
Architecture

Core Concepts

Concepts
Understanding Tekton Hub
Permission Description

Configure

Tekton Hub Configuration
Adding Custom Catalogs

Tutorials

Creating a Custom Catalog
Writing Tasks for Tekton Hub
Writing Pipelines for Tekton Hub

Results

Introduction
Architecture

Concepts

Core Concepts
Tekton Results
Quick Start
permissions

Configure

Database Configuration

Supply Chain Security

Introduction
Architecture

Concepts

Core Concepts
Understanding Tekton Chains
Quick Start

API Reference

Introduction

Kubernetes APIs

Pipelines

Pipeline [tekton.dev/v1]
Task [tekton.dev/v1]
PipelineRun [tekton.dev/v1]
TaskRun [tekton.dev/v1]
ClusterTask [tekton.dev/v1]
Run [tekton.dev/v1]
CustomRun [tekton.dev/v1]
StepAction [tekton.dev/v1]
VerificationPolicy [tekton.dev/v1alpha1]
ResolutionRequest [resolution.tekton.dev/v1beta1]

Triggers

Trigger [triggers.tekton.dev/v1beta1]
TriggerTemplate [triggers.tekton.dev/v1beta1]
EventListener [triggers.tekton.dev/v1beta1]
TriggerBinding [triggers.tekton.dev/v1beta1]
Interceptor [triggers.tekton.dev/v1alpha1]
ClusterTriggerBinding [triggers.tekton.dev/v1beta1]
ClusterInterceptor [triggers.tekton.dev/v1alpha1]

Operator

TektonConfig [operator.tekton.dev/v1alpha1]
TektonInstallerSet [operator.tekton.dev/v1alpha1]
TektonPipeline [operator.tekton.dev/v1alpha1]
TektonTrigger [operator.tekton.dev/v1alpha1]
TektonChain [operator.tekton.dev/v1alpha1]
TektonHub [operator.tekton.dev/v1alpha1]
TektonResult [operator.tekton.dev/v1alpha1]
TektonInstallerSet [operator.tekton.dev/v1alpha1]
OpenShift Pipelines as Code [operator.tekton.dev/v1alpha1]

Advanced APIs

Results

Introduction to API Usage
Results List
Results Details
Result records List
Result logs List
📝 Edit this page on GitHub
Previous PageEventListener
Next PageInterceptor

#Trigger

A Trigger is a key component in Tekton Triggers that specifies what happens when an EventListener detects an event. It connects event data to pipeline execution by defining how incoming data should be processed, extracted, and used to create Kubernetes resources.

#TOC

#Terminology Explanation

TermDescription
TriggerA Tekton resource that defines what happens when an event is detected, linking event data to pipeline execution.
TriggerBindingA resource that extracts fields from event payloads and binds them to named parameters.
TriggerTemplateA resource that specifies which resources to create (like TaskRuns or PipelineRuns) when an event is received.
EventListenerA Kubernetes service that listens for events and processes them according to defined Triggers.
InterceptorAn optional component that processes and filters event data before it's passed to TriggerBindings and TriggerTemplates.

#Why We Need Trigger

#The Challenge of Event-Driven CI/CD

In traditional CI/CD systems, connecting external events (like Git pushes or webhook calls) to pipeline execution requires:

  • Custom integration code for each event source
  • Manual configuration to map event data to pipeline parameters
  • Complex logic to determine when and how to run specific pipelines
  • Separate handling for different environments and conditions

This approach leads to:

  • Tight coupling between event sources and pipeline execution
  • Duplication of integration code across projects
  • Difficulty in maintaining and evolving the system
  • Limited reusability of integration patterns

#How Trigger Addresses These Problems

Tekton Trigger provides a declarative, Kubernetes-native way to:

  1. Define event processing logic: Specify exactly how events should be processed without custom code
  2. Extract relevant data: Use TriggerBindings to extract specific fields from event payloads
  3. Create appropriate resources: Use TriggerTemplates to dynamically create the right resources based on event data
  4. Filter and transform events: Apply Interceptors to validate, filter, and transform event data before processing
  5. Separate concerns: Decouple event reception from resource creation for better maintainability

This approach enables a fully event-driven CI/CD system that can respond automatically to various external events while maintaining flexibility and reusability.

#Advantages

  • Declarative configuration: Define event-to-pipeline connections using Kubernetes resources
  • Reusability: Create reusable Triggers that can be applied across multiple projects
  • Flexibility: Support for various event sources (GitHub, GitLab, generic webhooks, etc.)
  • Extensibility: Custom Interceptors can be created for specialized event processing
  • Separation of concerns: Clear separation between event reception, data extraction, and resource creation
  • Security: Built-in support for event validation and filtering
  • Kubernetes-native: Integrates seamlessly with the Kubernetes ecosystem

#Applicable Scenarios

Triggers are essential in the following scenarios:

  1. Automated CI/CD Pipelines: Automatically start builds and deployments when code is pushed to a repository.

  2. Multi-environment Deployments: Use the same event data but trigger different pipelines for different environments.

  3. ChatOps: Execute pipelines in response to comments in pull requests or issues.

  4. Scheduled Operations: Combine with cron jobs to trigger periodic maintenance or testing pipelines.

  5. Cross-service Workflows: Trigger pipelines when events occur in other systems (e.g., issue trackers, monitoring systems).

  6. GitOps: Automatically apply configuration changes when Git repositories are updated.

#Constraints and Limitations

  • Triggers require an EventListener to receive and process events
  • Each EventListener creates a Kubernetes service that needs to be accessible to event sources
  • Complex event processing might require custom Interceptors
  • Event sources must be able to send HTTP requests to the EventListener
  • Webhook security considerations must be addressed (authentication, authorization)

#Principles

#Trigger Structure

A Trigger resource in Tekton has the following structure:

apiVersion: triggers.tekton.dev/v1beta1
kind: Trigger
metadata:
  name: trigger-name
spec:
  # Optional: Process and filter events
  interceptors:
    - ref:
        name: "interceptor-name"
      params:
        - name: "param-name"
          value: "param-value"

  # Extract data from events
  bindings:
    - ref: binding-name  # Reference existing TriggerBinding
    # Or embed binding directly
    - name: param-name
      value: $(body.field.path)

  # Specify resources to create
  template:
    ref: template-name  # Reference existing TriggerTemplate
    # Or embed template directly
    # spec: ...

  # Optional: ServiceAccount for resource creation
  serviceAccountName: service-account-name

#Key Components and Their Relationships

  1. Interceptors: Process incoming events before they reach bindings and templates

    • Filter events based on specific criteria
    • Transform event data
    • Add additional data to the event payload
    • Validate event authenticity
  2. Bindings: Extract data from event payloads

    • Can reference existing TriggerBindings or ClusterTriggerBindings
    • Can be embedded directly in the Trigger
    • Multiple bindings can be combined in a single Trigger
  3. Template: Defines which resources to create

    • Can reference existing TriggerTemplates
    • Can be embedded directly in the Trigger
    • Uses parameters extracted by bindings
  4. ServiceAccount: Provides necessary permissions for creating resources

    • Must have permissions to create the resources defined in the template

#Configuration Examples

#GitHub Pull Request Trigger

apiVersion: triggers.tekton.dev/v1beta1
kind: Trigger
metadata:
  name: github-pull-request-trigger
spec:
  interceptors:
    - ref:
        name: "github"
      params:
        - name: "eventTypes"
          value: ["pull_request"]
    - ref:
        name: "cel"
      params:
        - name: "filter"
          value: "body.action in ['opened', 'synchronize', 'reopened']"
        - name: "overlays"
          value:
            - key: truncated_sha
              expression: "body.pull_request.head.sha.truncate(7)"
  bindings:
    - name: git-revision
      value: $(body.pull_request.head.sha)
    - name: git-repository-url
      value: $(body.repository.clone_url)
    - name: pull-request-number
      value: $(body.number)
  template:
    ref: pull-request-template

#GitLab Push Event Trigger

Based on the GitLab events documentation provided:

apiVersion: triggers.tekton.dev/v1beta1
kind: Trigger
metadata:
  name: gitlab-push-trigger
spec:
  interceptors:
    - ref:
        name: "gitlab"
      params:
        - name: "eventTypes"
          value: ["Push Hook"]
  bindings:
    - name: git-revision
      value: $(body.checkout_sha)
    - name: git-repository-url
      value: $(body.project.git_http_url)
    - name: git-repo-name
      value: $(body.project.name)
    - name: git-commit-message
      value: $(body.commits[0].message)
  template:
    ref: gitlab-ci-template

#Important Parameter Explanations Related to Trigger

#Interceptors

Interceptors are powerful components that process events before they reach TriggerBindings and TriggerTemplates.

#Applicable Scenarios

  • Validating webhook signatures
  • Filtering events based on specific criteria
  • Transforming event data
  • Adding additional context to events

#Constraints and Limitations

  • Each interceptor adds processing time to event handling
  • Complex filtering logic may require CEL expressions
  • Custom interceptors require additional deployment and management

#Principles/Parameter Explanation

Common interceptors include:

  • GitHub: Validates GitHub webhook signatures and filters by event type
  • GitLab: Validates GitLab webhook signatures and filters by event type
  • BitBucket: Validates BitBucket webhook signatures and filters by event type
  • CEL: Uses Common Expression Language for filtering and transformation
  • Webhook: Validates webhook signatures using a secret

#Bindings

The bindings field in a Trigger specifies how to extract data from events.

#Applicable Scenarios

  • Extracting Git commit information
  • Capturing metadata about pull requests or merge requests
  • Retrieving repository information
  • Accessing custom headers or payload fields

#Configuration Examples

bindings:
  # Reference existing TriggerBinding
  - ref: common-git-binding

  # Embed binding directly
  - name: custom-field
    value: $(body.custom.field)

  # Reference ClusterTriggerBinding
  - ref: cluster-git-binding
    kind: ClusterTriggerBinding

#Reference Materials

  • Tekton Triggers Documentation
  • Trigger Official Documentation
  • EventListener Documentation
  • TriggerBinding Documentation
  • TriggerTemplate Documentation
  • Interceptors Documentation