Tekton – Welcome to Tekton

Docs: Clone a git repository with Tekton

Mon, 01 Jan 0001 00:00:00 +0000

This guide shows you how to:

Create a Task to clone source code from a git repository.
Create a second Task to read the source code from a shared Workspace.

If you are already familiar with Tekton and just want to see the example, you can skip to the full code samples.

Prerequisites

To follow this How-to you must have a Kubernetes cluster up and running and kubectl properly configured to issue commands to your cluster.

Install Tekton Pipelines:

kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml

See the Pipelines installation documentation for other installation options.

Install the Tekton CLI, tkn, on your machine.

If this is your first time using Tekton Pipelines, we recommend that you complete the Getting Started tutorials before proceeding with this guide.

Pull source code from git

In this section you are going to create a Pipeline containing a Task to pull code from a git repository.

Create the Pipeline

One practical aspect of Tekton Tasks and Pipelines is that they are reusable. There’s a community hub with a curated list of Pipelines and Tasks that you can include in your own CI/CD workflow. You are going to reuse one of those Tasks in this guide.

Create a new Pipeline, pipeline.yaml:
```
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: clone-read
```
The name clone-read is going to be used by the PipelineRun to refer to this Pipeline. This name can also be used with the CLI, to check logs, delete the pipeline, etc.

Add the repository URL to the list of Pipeline parameters:

spec:
  description: | 
    This pipeline clones a git repo, then echoes the README file to the stdout.
  params:
  - name: repo-url
    type: string
    description: The git repo URL to clone from.

The params section contains a list of parameters to be used by the Tasks in this Pipeline. For now there is only one, repo-url.

Add a Workspace, a shared volume to store the code this task is going to download:

workspaces:
- name: shared-data
  description: | 
    This workspace contains the cloned repo files, so they can be read by the
    next task.

Create the Task that is going to use the parameter and the Workplace that you just defined:
```
tasks:
- name: fetch-source
  taskRef:
    name: git-clone
  workspaces:
  - name: output
    workspace: shared-data
  params:
  - name: url
    value: $(params.repo-url)
```
This Task, fetch-source, refers to another Task, git-clone; to be installed from the community hub. A Task has its own params and workspaces passed down from the ones defined at Pipeline level. In this case, the names for the parameter url and the Workspace output are the the ones expected by the git clone Task spec. See the git clone documentation for more parameters and options.

Check the full code samples to see how all the pieces fit together in the file.

Create the PipelineRun

Now that you have a Pipeline, to instantiate it and set the actual values, create a PipelineRun, pipelinerun.yaml:

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  generateName: clone-read-run-
spec:
  pipelineRef:
    name: clone-read
  podTemplate:
    securityContext:
      fsGroup: 65532

This PipelineRun instantiates clone-read, as specified by the pipelineRef target in the spec section.

Instantiate the Workspace:

workspaces:
- name: shared-data
  volumeClaimTemplate:
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi

This creates a Persistent Volume Claim to store the cloned files. The name shared-data matches the name used in the Pipeline.

Set the value of the repository URL parameter:
```
params:
- name: repo-url
  value: https://github.com/tektoncd/website
```
For this example you are going to clone the Tekton documentation website source code.

Check the full code samples to see full PipelineRun code.

Git authentication

For the sake of this example, we are using a public repository, which requires no authentication. If you want to clone a private repository, you must create a Kubernetes Secret with your credentials, then pass that secret to your Task as a Workspace.

Before you proceed, you have to set up SSH authentication with your git provider. The process may be slightly different in each case:

The following steps show you how to authenticate using an SSH key. For other forms of authentication check the git-clone Task documentation and the Git authentication section in the Pipelines documentation.

Create a Kubernetes Secret with your credentials, for example:
```
apiVersion: v1
kind: Secret
metadata:
  name: git-credentials
data:
  id_rsa: AS0tLS...
  known_hosts: AG033S...
  config: GS0FFL...
```
The values for the fields under data are the corresponding base64-encoded files in the .ssh directory. For example, for id_rsa copy-paste the output of:
```
cat ~/.ssh/id_rsa | base64 -w0
```

Update pipeline.yaml, add a new Workspace to both the Pipeline and the Task:

workspaces:
- name: shared-data
  description: | 
    This workspace contains the cloned repo files, so they can be read by the
    next task.
- name: git-credentials
  description: My ssh credentials
tasks:
- name: fetch-source
  taskRef:
    name: git-clone
  workspaces:
  - name: output
    workspace: shared-data
  - name: ssh-directory
    workspace: git-credentials

The Workspace git-credentials is defined at Pipeline level and then passed down to the Task as ssh-directory, which is the name the Task expects.

Update pipelinerun.yaml to use the Secret as a Workspace and change the git URL from https to SSH:

workspaces:
- name: shared-data
  volumeClaimTemplate:
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi
- name: git-credentials
  secret:
    secretName: git-credentials
params:
- name: repo-url
  value: git@github.com:tektoncd/website.git

The new Workspace name, git-credentials, matches the Workspace added to the Pipeline.

Use the source code in a second task

To learn how to share data between Tasks using a Workspace, you are going to create a second Task that displays the README file from the cloned git repository. You can find more useful examples in the How-to section and the examples folder in the Pipelines git repository.

Add a new entry to the tasks section of pipeline.yaml:
```
- name: show-readme
  runAfter: ["fetch-source"]
  taskRef:
    name: show-readme
  workspaces:
  - name: source
    workspace: shared-data
```
This is referencing the Task show-readme. Unlike git clone, this Task is not from the Tekton community hub, you have to create it yourself.

Create a file called show-readme.yaml and add the following:

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: show-readme
spec:
  description: Read and display README file.
  workspaces:
  - name: source
  steps:
  - name: read
    image: alpine:latest
    script: | 
      #!/usr/bin/env sh
      cat $(workspaces.source.path)/README.md

This Task uses a Workspace that was already set. You don’t have to update pipelinerun.yaml.

Run the Pipeline

Install a Task from Tekton Hub

To use the git clone Task in your pipeline, you have to install it on your cluster first. You can do this with the tkn command:

tkn hub install task git-clone

Or using kubectl:

kubectl apply -f \
https://raw.githubusercontent.com/tektoncd/catalog/main/task/git-clone/0.6/git-clone.yaml

Alternatively, you can bundle a Task or a Pipeline and let your Pipeline fetch it directly from a registry.

Apply the files

Now you are ready to test the code.

Apply the show-readme Task:
```
kubectl apply -f show-readme.yaml
```
Apply the Pipeline:
```
kubectl apply -f pipeline.yaml
```

Create the PipelineRun:

kubectl create -f pipelinerun.yaml

This creates a PipelineRun with a unique name each time:

pipelinerun.tekton.dev/clone-read-run-4kgjr created

Use the PipelineRun name from the output of the previous step to monitor the Pipeline execution:

tkn pipelinerun logs  clone-read-run-4kgjr -f

You may have to wait a few seconds. The output confirms that the respository was cloned succesfully and displays the README file at the end:

[fetch-source : clone] + '[' false '=' true ]
[fetch-source : clone] + '[' false '=' true ]
[fetch-source : clone] + '[' false '=' true ]
[fetch-source : clone] + CHECKOUT_DIR=/workspace/output/
[fetch-source : clone] + '[' true '=' true ]
[fetch-source : clone] + cleandir
[fetch-source : clone] + '[' -d /workspace/output/ ]
[fetch-source : clone] + rm -rf '/workspace/output//*'
[fetch-source : clone] + rm -rf '/workspace/output//.[!.]*'
[fetch-source : clone] + rm -rf '/workspace/output//..?*'
[fetch-source : clone] + test -z 
[fetch-source : clone] + test -z 
[fetch-source : clone] + test -z 
[fetch-source : clone] + /ko-app/git-init '-url=https://github.com/tektoncd/website' '-revision=' '-refspec=' '-path=/workspace/output/' '-sslVerify=true' '-submodules=true' '-depth=1' '-sparseCheckoutDirectories='
[fetch-source : clone] {"level":"info","ts":1652300245.5099113,"caller":"git/git.go:170","msg":"Successfully cloned https://github.com/tektoncd/website @ 4930334b17edeaa737e2e6d0c7f7139b0afb1896 (grafted, HEAD) in path /workspace/output/"}
[fetch-source : clone] {"level":"info","ts":1652300245.5349698,"caller":"git/git.go:208","msg":"Successfully initialized and updated submodules in path /workspace/output/"}
[fetch-source : clone] + cd /workspace/output/
[fetch-source : clone] + git rev-parse HEAD
[fetch-source : clone] + RESULT_SHA=4930334b17edeaa737e2e6d0c7f7139b0afb1896
[fetch-source : clone] + EXIT_CODE=0
[fetch-source : clone] + '[' 0 '!=' 0 ]
[fetch-source : clone] + printf '%s' 4930334b17edeaa737e2e6d0c7f7139b0afb1896
[fetch-source : clone] + printf '%s' https://github.com/tektoncd/website

[show-readme : read] # TektonCD Website
[show-readme : read] 
[show-readme : read] This repo contains the code behind [the Tekton org's](https://github.com/tektoncd)
[show-readme : read] website at [tekton.dev](https://tekton.dev).
[show-readme : read] 
[show-readme : read] For more information on the Tekton Project, see
[show-readme : read] [the community repo](https://github.com/tektoncd/community).
[show-readme : read] 
[show-readme : read] For more information on contributing to the website see:
[show-readme : read] 
[show-readme : read] * [CONTRIBUTING.md](CONTRIBUTING.md)
[show-readme : read] * [DEVELOPMENT.md](DEVELOPMENT.md)

Full code samples

The Pipeline:

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: clone-read
spec:
  description: | 
    This pipeline clones a git repo, then echoes the README file to the stout.
  params:
  - name: repo-url
    type: string
    description: The git repo URL to clone from.
  workspaces:
  - name: shared-data
    description: | 
      This workspace contains the cloned repo files, so they can be read by the
      next task.
  - name: git-credentials
    description: My ssh credentials
  tasks:
  - name: fetch-source
    taskRef:
      name: git-clone
    workspaces:
    - name: output
      workspace: shared-data
    - name: ssh-directory
      workspace: git-credentials
    params:
    - name: url
      value: $(params.repo-url)
  - name: show-readme
    runAfter: ["fetch-source"]
    taskRef:
      name: show-readme
    workspaces:
    - name: source
      workspace: shared-data

The PipelineRun:

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  generateName: clone-read-run-
spec:
  pipelineRef:
    name: clone-read
  podTemplate:
    securityContext:
      fsGroup: 65532
  workspaces:
  - name: shared-data
    volumeClaimTemplate:
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 1Gi
  - name: git-credentials
    secret:
      secretName: git-credentials
  params:
  - name: repo-url
    value: git@github.com:tektoncd/website.git

The show-readme Task:

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: show-readme
spec:
  description: Read and display README file.
  workspaces:
  - name: source
  steps:
  - name: read
    image: alpine:latest
    script: | 
      #!/usr/bin/env sh
      cat $(workspaces.source.path)/README.md

The Kubernetes Secret. These values are not real, check the section about git authentication to figure out how to encode your credentials.

apiVersion: v1
kind: Secret
metadata:
  name: git-credentials
data:
  id_rsa: AS0tLS...
  known_hosts: AG033S...

Docs: Content guidelines

Mon, 01 Jan 0001 00:00:00 +0000

Follow these guidelines when planning and writing Tekton documentation.

Types of content

Each page in the Tekton documentation set must fall into one of the following categories:

Tutorials - These are introductory guides, focused on new users:
- Task-oriented
- Make sure it works: For Tekton, this means pick a runtime and stick with it throughout the entire tutorial, so you can have reproducible steps that a newcomer can copy-paste.
- Do not explain anything in detail, focus on doing. This is a common pitfall, trying to explain things too early.
- Do not provide more than one way of doing things. Pick the easiest path and go with it. This is another common pitfall, trying to show everything you can do in an introductory guide.
- Show results immediately.
How-to guides - These are docs that explain how to complete a particular task:
- Goal oriented.
- Assumes some knowledge from the user, no need to start from scratch.
- Focus on the goal at hand.
- It’s fine to show several ways to achieve the goal, but there’s no need to be comprehensive. (That’s what reference docs are for).
- Provide a descriptive title.
Reference Guides - These provide the technical details for everything Tekton does. The most common example is the API reference docs:
- Be accurate
- Mirror the codebase when possible, so your reader knows what to expect.
Explanations - Conceptual information:
- Descriptive content, explain how things work
- Do not include steps here

You can find an in-depth discussion about this documentation framework in the Grand Unified Theory of Documentation.

Structure

We want our documentation to be easily digestible, so make sure your writing is clear and concise. Follow these simple guidelines:

Break up long thoughts into multiple sentences.
Break up longer documents into logical sections.
Use paragraphs to separate thoughts and ideas.
Ensure paragraphs flow into one another - that is, they are logically connected.
Use headings and subheadings to indicate topics and sub-topics. Don’t use more than 3 subheading levels.

Style and tone

Always use active voice. It’s much easier to parse and more user-friendly (relatable) than passive. Passive voice sounds stuffy and officious. It takes much more brain work to understand and causes the reader to zone out.

Do	Don't
The installer copies the files to the destination directory.	The files being installed are copied to the destination directory by the installer.

Never use “should” or “might.” These words introduce uncertainty. We’re either sure how our software works or we’re not.

Do	Don't
Click Build to start your build.	When you click Build, your build should start.

Don’t use future tense unless no other way exists to convey the information. Future tense creates an unwanted deferral of the result, while the result of each step should be immediate. For example:

Do	Don't
Click Build to start your build.	When you click Build, your build will start.

Avoid repetition. Repetition is a “mental stumbling block” that gets in the way of the reader’s comprehension of the thought or topic. For example:

Do	Don't
Smurfcaptor supports single- and multi-Smurf capture events, including batch processing.	Smurfcaptor supports single- and multi-Smurf capture events. Smurfcaptor also supports batch processing.

Never use “we.” The reader will wonder whether they’re part of the “we” or not. For example:

Do	Don't
Version 3.0 adds support for Smurf counting.	In version 3.0 we added Smurf counting support.

Never use “might” or “may.” “May” is often confused with “might” but they are not the same. “Might” introduces uncertainty just like “should,” while “may” implies the permission has been granted and not that an option or action is available to the user. For example:

Do	Don't
The build starts when you click Build.	The build might start when you click Build.
You can choose either high or low Smurf sensitivity.	You may choose high or low Smurf sensitivity.

Docs: Contribute Code

Mon, 01 Jan 0001 00:00:00 +0000

If you would like to contribute code to Tekton, we’d love your help! Tekton is an open source project and we welcome contributions from everyone.

Getting started

Check out the Tekton Community page for an overview of how to get involved. The community page covers:

Contribution standards - code of conduct, design principles, and coding standards.
Contribution process - how to find something to work on, propose features, submit pull requests, and climb the contributor ladder.
Community spaces - Slack, mailing lists, working groups, and meetings.

Finding something to work on

Browse the GitHub repositories under the tektoncd organization. Look for issues labeled good first issue or help wanted to get started.

You can also check the community process documentation for more guidance.

Key resources

Resource	Description
Contributor ladder	How to grow your role in the project
Design principles	Core design values for Tekton
Code standards	Coding conventions and standards
Commit standards	Commit message conventions
Pull request reviews	How the review process works
Propose new features	TEP process for feature proposals

I need help!

If you’re not sure where to start, join the Tekton Slack and ask in the relevant project channel. You can also reach out on the tekton-dev mailing list.

Docs: Getting started with Tasks

Mon, 01 Jan 0001 00:00:00 +0000

This tutorial shows you how to

Create a Kubernetes cluster with minikube.
Install Tekton pipelines.
Create a Task.
Use TaskRun to instantiate and run the Task.

Prerequisites

Install minikube. You only have to complete the step 1, “Installation”.
Install kubectl.

Create a Kubernetes cluster

Create a cluster:

minikube start --kubernetes-version v1.33.1

The process takes a few seconds, you see an output similar to the following, depending on the minikube driver that you are using:

😄  minikube v1.36.0 on Darwin 15.5 (arm64)
✨  Using the qemu2 driver based on user configuration
🌐  Automatically selected the builtin network
👍  Starting "minikube" primary control-plane node in "minikube" cluster
🔥  Creating qemu2 VM (CPUs=2, Memory=6000MB, Disk=20000MB) ...
📦  Preparing Kubernetes v1.33.1 on containerd 1.7.23 ...
    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...
    ▪ Configuring RBAC rules ...
🔗  Configuring bridge CNI (Container Networking Interface) ...
🔎  Verifying Kubernetes components...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: default-storageclass, storage-provisioner
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

You can check that the cluster was successfully created with kubectl:

kubectl cluster-info

The output confirms that Kubernetes is running:

Kubernetes control plane is running at https://localhost:64858
CoreDNS is running at https://localhost:64858/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

Install Tekton Pipelines

To install the latest version of Tekton Pipelines, use kubectl:

kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml

Monitor the installation:

kubectl get pods --namespace tekton-pipelines --watch

When both tekton-pipelines-controller and tekton-pipelines-webhook show 1/1 under the READY column, you are ready to continue. For example:

NAME                                          READY   STATUS    RESTARTS   AGE
tekton-events-controller-786b59d5cd-jt7d9     0/1     Running   0          2s
tekton-pipelines-controller-59b6cdbbc-2kw2w   0/1     Running   0          2s
tekton-pipelines-webhook-74b5cdfcc4-g4qj2     0/1     Running   0          2s
tekton-pipelines-controller-59b6cdbbc-2kw2w   1/1     Running   0          11s
tekton-events-controller-786b59d5cd-jt7d9     1/1     Running   0          11s
tekton-pipelines-webhook-74b5cdfcc4-g4qj2     1/1     Running   0          11s

Hit Ctrl + C to stop monitoring.

Create and run a basic Task

A Task, represented in the API as an object of kind Task, defines a series of Steps that run sequentially to perform logic that the Task requires. Every Task runs as a pod on the Kubernetes cluster, with each step running in its own container.

To create a Task, open your favorite editor and create a file named hello-world.yaml with the following content:

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: hello
spec:
  steps:
    - name: echo
      image: alpine
      script: |
        #!/bin/sh
        echo "Hello World"

Apply the changes to your cluster:
```
kubectl apply --filename hello-world.yaml
```
The output confirms that the Task was created successfully:
```
task.tekton.dev/hello created
```

A TaskRun object instantiates and executes this Task. Create another file named hello-world-run.yaml with the following content:

apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: hello-task-run
spec:
  taskRef:
    name: hello

Apply the changes to your cluster to launch the Task:
```
kubectl apply --filename hello-world-run.yaml
```
Verify that everything worked correctly:
```
kubectl get taskrun hello-task-run
```
The output of this command shows the status of the Task:
```
NAME             SUCCEEDED   REASON      STARTTIME   COMPLETIONTIME
hello-task-run   True        Succeeded   28s         3s
```
The value True under SUCCEEDED confirms that TaskRun completed with no errors.

Take a look at the logs:

kubectl logs --selector=tekton.dev/taskRun=hello-task-run

The output displays the message:

Hello World

Cleanup

To learn about Tekton Pipelines, skip this section and proceed to the next tutorial.

To delete the cluster that you created for this guide run:

minikube delete

The output confirms that the cluster was deleted:

🔥  Deleting "minikube" in qemu2 ...
💀  Removed all traces of the "minikube" cluster.

Docs: Local Kubernetes cluster

Mon, 01 Jan 0001 00:00:00 +0000

There are several tools to run a local Kubernetes cluster on your computer. The Tekton documentation often includes instructions for either minikube or kind.

See the corresponding minikube and kind documentation to learn how to install and set up a cluster on your computer.

You can find some additional resources on the Tekton repositories:

Instructions to run both tools with a local registry are available on the Pipelines repository.
You can find some convenience scripts to run Tekton components with kind on the plumbing repository.

Docs: Overview

Mon, 01 Jan 0001 00:00:00 +0000

What is Tekton?

Tekton is a cloud-native solution for building CI/CD pipelines. It consists of Tekton Pipelines, which provides the building blocks, and of supporting components, such as Tekton CLI and Tekton Catalog, that make Tekton a complete ecosystem. Tekton is an incubating project at the Cloud Native Computing Foundation (CNCF).

Tekton installs and runs as an extension on a Kubernetes cluster and comprises a set of Kubernetes Custom Resources that define the building blocks you can create and reuse for your pipelines. Once installed, Tekton Pipelines becomes available via the Kubernetes CLI (kubectl) and via API calls, just like pods and other resources.

Who uses Tekton?

Tekton users typically fall into the following categories:

Platform engineers who build CI/CD systems for the developers in their organization.
Developers who use those CI/CD systems to do their work.

What are the benefits of Tekton?

Tekton provides the following benefits to builders and users of CI/CD systems:

Customizable. Tekton entities are fully customizable, allowing for a high degree of flexibility. Platform engineers can define a highly detailed catalog of building blocks for developers to use in a wide variety of scenarios.
Reusable. Tekton entities are fully portable, so once defined, anyone within the organization can use a given pipeline and reuse its building blocks. This allows developers to quickly build complex pipelines without “reinventing the wheel.”
Expandable. Tekton Catalog is a community-driven repository of Tekton building blocks. You can quickly create new and expand existing pipelines using pre-made components from the Tekton Catalog.
Standardized. Tekton installs and runs as an extension on your Kubernetes cluster and uses the well-established Kubernetes resource model. Tekton workloads execute inside Kubernetes containers.
Scalable. To increase your workload capacity, you can simply add nodes to your cluster. Tekton scales with your cluster without the need to redefine your resource allocations or any other modifications to your pipelines.

What are the components of Tekton?

Tekton consists of the following components:

Tekton Pipelines is the foundation of Tekton. It defines a set of Kubernetes Custom Resources that act as building blocks from which you can assemble CI/CD pipelines.
Tekton Triggers allows you to instantiate pipelines based on events. For example, you can trigger the instantiation and execution of a pipeline every time a PR is merged against a GitHub repository. You can also build a user interface that launches specific Tekton triggers.
Tekton CLI provides a command-line interface called tkn, built on top of the Kubernetes CLI, that allows you to interact with Tekton.
Tekton Dashboard is a Web-based graphical interface for Tekton Pipelines that displays information about the execution of your pipelines. It is currently a work-in-progress.
Tekton Catalog is a repository of high-quality, community-contributed Tekton building blocks - Tasks, Pipelines, and so on - that are ready for use in your own pipelines.
Tekton Hub is a Web-based graphical interface for accessing the Tekton Catalog.
Tekton Operator is a Kubernetes Operator pattern that allows you to install, update, and remove Tekton projects on your Kubernetes cluster.
Tekton Chains provides tools to generate, store, and sign provenance for artifacts built with Tekton Pipelines.
Pipelines-as-Code brings a Git-native CI/CD workflow to Tekton, allowing you to define your pipelines in a .tekton/ directory alongside your source code. It integrates with GitHub, GitLab, Bitbucket, and Forgejo.

How do I work with Tekton?

To install Tekton, you need a Kubernetes cluster running a version of Kubernetes specified for the current Tekton release. Once installed, you can interact with Tekton using one of the following:

The tkn CLI, also known as the Tekton CLI, is the preferred command-line method for interacting with Tekton. tkn provides a quick and streamlined experience, including high-level commands and color coding. To use it, you only need to be familiar with Tekton.
The kubectl CLI, also known as the Kubernetes CLI, provides substantially more granularity for controlling Tekton at the expense of higher complexity. Interacting with Tekton via kubectl is typically reserved for debugging your pipelines and troubleshooting your builds.
The Tekton APIs, currently available for Pipelines and Triggers, allow you to programmatically interact with Tekton components. This is typically reserved for highly customized CI/CD systems. In most scenarios, tkn and kubectl are the preferred methods of controlling Tekton.

We also recommend having the following items configured on your Kubernetes cluster:

Persistent volume claims for specifying inputs and outputs.
Permissions appropriate to your environment and business needs.
Storage for building and pushing images (if applicable).

What can I do with Tekton?

Tekton introduces the concept of Tasks, which specify the workloads you want to run:

Task - defines a series of ordered Steps, and each Step invokes a specific build tool on a specific set of inputs and produces a specific set of outputs, which can be used as inputs in the next Step.
Pipeline - defines a series of ordered Tasks, and just like Steps in a Task, a Task in a Pipeline can use the output of a previously executed Task as its input.
TaskRun - instantiates a specific Task to execute on a particular set of inputs and produce a particular set of outputs. In other words, the Task tells Tekton what to do, and a TaskRun tells Tekton what to do it on, as well as any additional details on how to exactly do it, such as build flags.
PipelineRun - instantiates a specific Pipeline to execute on a particular set of inputs and produce a particular set of outputs to particular destinations.

Each Task executes in its own Kubernetes Pod. Thus, by default, Tasks within a Pipeline do not share data. To share data among Tasks, you must explicitly configure each Task to make its outputs available to the next Task and to ingest the outputs of a previously executed Task as its inputs, whichever is applicable.

When to use which?

Task - useful for simpler workloads such as running a test, a lint, or building a Kaniko cache. A single Task executes in a single Kubernetes Pod, uses a single disk, and generally keeps things simple.
Pipeline - useful for complex workloads, such as static analysis, as well as testing, building, and deploying complex projects.

I want to learn more!

See the Tekton concept model to learn more about the basics of how Tekton tasks and pipelines interact.
Run your first pipeline following the Getting Started guide.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Config

TektonConfig custom resource is the top most component of the operator which allows user to install and customize all other components at a single place.

Operator provides support for installing and managing following operator components through TektonConfig:

Other than the above components depending on the platform operator also provides support for

On both Kubernetes and OpenShift
- TektonChain
- TektonResult
On Kubernetes
- TektonDashboard
On OpenShift
- TektonAddon
- OpenShiftPipelinesAsCode
When scheduler multi-cluster is enabled with Hub role (both Kubernetes and OpenShift)
- TektonMulticlusterProxyAAE

The TektonConfig CR provides the following features

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  targetNamespace: tekton-pipelines
  targetNamespaceMetadata:
    labels: {}
    annotations: {}
  profile: all
  config:
    nodeSelector: <>
    tolerations: []
    priorityClassName: system-cluster-critical
  chain:
    disabled: false
  pipeline:
    await-sidecar-readiness: true
    coschedule: workspaces
    disable-creds-init: false
    disable-home-env-overwrite: true
    disable-working-directory-overwrite: true
    disable-inline-spec: "pipeline,pipelinerun,taskrun"
    enable-api-fields: beta
    enable-bundles-resolver: true
    enable-cel-in-whenexpression: false
    enable-cluster-resolver: true
    enable-custom-tasks: true
    enable-git-resolver: true
    enable-hub-resolver: true
    enable-param-enum: false
    enable-provenance-in-status: true
    enable-step-actions: false
    enforce-nonfalsifiability: none
    keep-pod-on-cancel: false
    max-result-size: 4096
    metrics.count.enable-reason: false
    metrics.pipelinerun.duration-type: histogram
    metrics.pipelinerun.level: pipeline
    metrics.taskrun.duration-type: histogram
    metrics.taskrun.level: task
    # Tracing configuration (optional)
    # traces.enabled: true
    # traces.endpoint: "http://jaeger-collector.jaeger.svc.cluster.local:4318/v1/traces"
    # traces.credentialsSecret: ""
    require-git-ssh-secret-known-hosts: false
    results-from: termination-message
    running-in-environment-with-injected-sidecars: true
    send-cloudevents-for-runs: false
    set-security-context: false
    trusted-resources-verification-no-match-policy: ignore
    performance:
      disable-ha: false
      buckets: 1
      replicas: 1
      threads-per-controller: 2
      kube-api-qps: 5.0
      kube-api-burst: 10
    options:
      disabled: false
      configMaps: {}
      deployments: {}
      webhookConfigurationOptions: {}
  pruner:
    disabled: false
    schedule: "0 8 * * *"
    resources:
      - taskrun
      - pipelinerun
    keep: 3
    # keep-since: 1440
    # NOTE: you can use either "keep" or "keep-since", not both
    prune-per-resource: true
  hub:
    params:
      - name: enable-devconsole-integration
        value: "true"
    options:
      disabled: false
      configMaps: {}
      deployments: {}
      webhookConfigurationOptions: {}
  dashboard:
    readonly: true
    options:
      disabled: false
      configMaps: {}
      deployments: {}
      webhookConfigurationOptions: {}
  result:
    disabled: false
    is_external_db: false
    options: {}
    performance:
      disable-ha: false
      buckets: 1
      replicas: 1
  trigger:
    disabled: false
platforms:
    openshift:
      pipelinesAsCode:
        additionalPACControllers:
          <controllerName>:
            enable: true
            configMapName:
            secretName:
            settings:
        enable: true
        settings:
          application-name: Pipelines as Code CI
          auto-configure-new-github-repo: "false"
          bitbucket-cloud-check-source-ip: "true"
          custom-console-name: ""
          custom-console-url: ""
          custom-console-url-pr-details: ""
          custom-console-url-pr-tasklog: ""
          error-detection-from-container-logs: "false"
          error-detection-max-number-of-lines: "50"
          error-detection-simple-regexp:
            ^(?P<filename>[^:]*):(?P<line>[0-9]+):(?P<column>[0-9]+):([
            ]*)?(?P<error>.*)
          error-log-snippet: "true"
          error-log-snippet-number-of-lines: "3"
          enable-cancel-in-progress-on-pull-requests: "false"
          enable-cancel-in-progress-on-push: "false"
          hub-catalog-name: tekton
          hub-url: https://api.hub.tekton.dev/v1
          require-ok-to-test-sha: "false"
          skip-push-event-for-pr-commits: "true"
          remote-tasks: "true"
          secret-auto-create: "true"
          secret-github-app-token-scoped: "true"
      options:
        disabled: false
        configMaps: {}
        deployments: {}
        webhookConfigurationOptions: {}

Look for the particular section to understand a particular field in the spec.

Target Namespace

This allows user to choose a namespace to install the Tekton Components such as pipelines, triggers.

By default, namespace would be tekton-pipelines for Kubernetes and openshift-pipelines for OpenShift.

Note: Namespace openshift-operators is not allowed in OpenShift as a targetNamespace.

Target Namespace Metadata

targetNamespaceMetadata allows user to add their custom labels and annotations to the target namespace via TektonConfig CR.

Profile

This allows user to choose which all components to install on the cluster. There are 3 profiles available:

all: This profile will install all components (TektonPipeline, TektonTrigger, TektonResult and TektonChain)
basic: This profile will install only TektonPipeline, TektonTrigger, TektonResult and TektonChain component
lite: This profile will install only TektonPipeline component

On Kubernetes, all profile will install TektonDashboard and on OpenShift TektonAddon will be installed.

Config

Config provides fields to configure deployments created by the Operator. This provides following fields:

User can pass the required fields and this would be passed to all Operator components which will get added in all deployments created by Operator.

Example:

config:
  nodeSelector:
    key: value
  tolerations:
    - key: "key1"
      operator: "Equal"
      value: "value1"
      effect: "NoSchedule"
  priorityClassName: system-node-critical

This is an Optional section.

NOTE: If spec.config.priorityClassName is used, then the required priorityClass is expected to be created by the user to get the Tekton resources pods in running state

Pipeline

Pipeline section allows user to customize the Tekton pipeline features. This allow user to customize the values in configmaps.

Refer to properties section in TektonPipeline for available options.

Some of the fields have default values, so operator will add them if user haven’t passed in CR. Other fields which doesn’t have default values won’t be passed unless user specify them in CR. User can find those here.

Example:

pipeline:
  disable-creds-init: false
  disable-home-env-overwrite: true
  disable-working-directory-overwrite: true
  enable-api-fields: stable
  enable-custom-tasks: false
  metrics.pipelinerun.duration-type: histogram
  metrics.pipelinerun.level: pipelinerun
  metrics.taskrun.duration-type: histogram
  metrics.taskrun.level: taskrun
  traces.enabled: true
  traces.endpoint: "http://jaeger-collector.jaeger.svc.cluster.local:4318/v1/traces"
  traces.credentialsSecret: "" # optional
  require-git-ssh-secret-known-hosts: false
  running-in-environment-with-injected-sidecars: true
  trusted-resources-verification-no-match-policy: ignore
  performance:
    replicas: 1
    disable-ha: false
    buckets: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10

Chain

Chain section allows user to customize the Tekton Chain features. This allows user to customize the values in configmaps

Refer to properties section in TektonChain for available options

Example:

chain:
  disabled: false # - `disabled` : if the value set as `true`, chains feature will be disabled (default: `false`)
  targetNamespace: tekton-pipelines
  generateSigningSecret: true # default value: false
  controllerEnvs:
    - name: MONGO_SERVER_URL # This is the only field supported at the moment which is optional and when added by user, it is added as env to Chains controller
      value: #value               # This can be provided same as env field of container
  artifacts.taskrun.format: in-toto
  artifacts.taskrun.storage: tekton,oci (comma separated values)
  artifacts.taskrun.signer: x509
  artifacts.oci.storage: oci (comma separated values)
  artifacts.oci.format: simplesigning
  artifacts.oci.signer: x509
  artifacts.pipelinerun.format: in-toto
  artifacts.pipelinerun.storage: tekton,oci (comma separated values)
  artifacts.pipelinerun.signer: x509
  storage.gcs.bucket: #value
  storage.oci.repository: #value
  storage.oci.repository.insecure: #value (boolean - true/false)
  storage.docdb.url: #value
  storage.grafeas.projectid: #value
  storage.grafeas.noteid: #value
  storage.grafeas.notehint: #value
  builder.id: #value
  signers.x509.fulcio.enabled: #value (boolean - true/false)
  signers.x509.fulcio.address: #value
  signers.x509.fulcio.issuer: #value
  signers.x509.fulcio.provider: #value
  signers.x509.identity.token.file: #value
  signers.x509.tuf.mirror.url: #value
  signers.kms.kmsref: #value
  signers.kms.kmsref.auth.address: #value
  signers.kms.kmsref.auth.token: #value
  signers.kms.kmsref.auth.oidc.path: #value
  signers.kms.kmsref.auth.oidc.role: #value
  signers.kms.kmsref.auth.spire.sock: #value
  signers.kms.kmsref.auth.spire.audience: #value
  transparency.enabled: #value (boolean - true/false)
  transparency.url: #value

Result

Result section allows user to customize the Tekton Result component, Refer to Result Spec section in TektonResult for available options.

Default Result configuration in TektonConfig looks like following if user doesn’t specified any configuration options

Example:

result:
  disabled: false
  is_external_db: false
  options: {}

User can customize Result configuration with following options

Example:

result:
  disabled: false # - `disabled` : if the value set as `true`, result component will be disabled (default: `false`)
  targetNamespace: tekton-pipelines
  is_external_db: false # By default, this is set to false, TektonOperator will create Tekton Results database. If set to true, an external database will be used, and Tekton Results will retrieve its database credentials from the Kubernetes secret named tekton-results-postgres
  db_host: localhost
  db_port: 5342
  db_sslmode: verify-full
  db_sslrootcert: /etc/tls/db/ca.crt
  db_enable_auto_migration: true
  log_level: debug
  logs_api: true
  logs_type: File
  logs_buffer_size: 90kb
  logs_path: /logs
  auth_disable: true
  logging_pvc_name: tekton-logs
  secret_name: # optional
  gcs_creds_secret_name: <value>
  gcc_creds_secret_key: <value>
  gcs_bucket_name: <value>
  loki_stack_name: #optional
  loki_stack_namespace: #optional
  prometheus_port: 9090
  prometheus_histogram: false

User can configure custom database secret name for internal/external database via Tekton Config CR.

Example:

result:
  db_secret_name: # custom database secret name
  db_secret_user_key: # optional: required if custom database secret user key is not "POSTGRES_USER"
  db_secret_password_key: # optional: required if custom database secret password key is not "POSTGRES_PASSWORD"

Pruner

Pruner provides auto clean up feature for the Tekton pipelinerun and taskrun resources. In the background pruner container runs tkn command.

Example:

pruner:
  disabled: false
  schedule: "0 8 * * *"
  startingDeadlineSeconds: 100 # optional
  resources:
    - taskrun
    - pipelinerun
  keep: 3
  # keep-since: 1440
  # NOTE: you can use either "keep" or "keep-since", not both
  prune-per-resource: true

disabled : if the value set as true, pruner feature will be disabled (default: false)
schedule: how often to run the pruner job. User can understand the schedule syntax here.
startingDeadlineSeconds: Optional deadline in seconds for starting the job if it misses scheduled time for any reason. Missed jobs executions will be counted as failed ones
resources: supported resources for auto prune are taskrun and pipelinerun
keep: maximum number of resources to keep while deleting or removing resources
keep-since: retain the resources younger than the specified value in minutes
prune-per-resource: if the value set as true (default value false), the keep applied to each resource. The resources(pipeline and/or task) taken dynamically from that namespace and applied.
example: in a namespace ns-1 I have two pipeline, named pipeline-1 and pipeline-2, the out come would be: tkn pipelinerun delete --pipeline=my-pipeline-1 --keep=3 --namespace=ns-1, tkn pipelinerun delete --pipeline=my-pipeline-2 --keep=3 --namespace=ns-1. the same way works for task too.
We do not see any benefit by enabling prune-per-resource=true, when you use keep-since. As keep-since is limiting the resources by time(irrespective of resource count), there is no change on the outcome.

Note:

if disabled: false and schedule: with empty value, global pruner job will be disabled. however, if there is a prune schedule (operator.tekton.dev/prune.schedule) annotation present with a value in a namespace. a namespace wide pruner jobs will be created.

Pruner Namespace annotations

By default pruner job will be created from the global pruner config (spec.pruner), though user can customize a pruner config to a specific namespace with the following annotations. If some of the annotations are not present or has invalid value, for that value, falls back to global value or skipped the namespace.

operator.tekton.dev/prune.skip - pruner job will be skipped to a namespace, if the value set as true
operator.tekton.dev/prune.schedule - pruner job will be created on a specific schedule
operator.tekton.dev/prune.keep - maximum number of resources will be kept
operator.tekton.dev/prune.keep-since - retain the resources younger than the specified value in minutes
operator.tekton.dev/prune.prune-per-resource - the keep or keep-since applied to each resource
operator.tekton.dev/prune.resources - can be taskrun and/or pipelinerun, both value can be specified with comma separated. example: taskrun,pipelinerun
operator.tekton.dev/prune.strategy - allowed values: either keep or keep-since

Note:

if a global value is not present the following values will be consider as default value
> resources: pipelinerun
> keep: 100

Scheduler

Scheduler section allows you to install and manage the Tekton Scheduler through TektonConfig. The Scheduler component uses Kueue and cert-manager; you must install Kueue and cert-manager CRDs before enabling the scheduler. For full pre-requisites and multi-cluster configuration details, see Tekton Scheduler.

Scheduler can be enabled by setting disabled to false in the scheduler section. If you are working with multi-cluster pipelines, you can enable multi-cluster from the scheduler config. In a multi-cluster environment a cluster can play the role of Hub or Spoke. The TektonConfig settings for Scheduler for Hub and Spoke are defined below.

Hub cluster

scheduler:
  disabled: false
  multi-cluster-disabled: false
  multi-cluster-role: Hub
  options: {}

Spoke cluster

scheduler:
  disabled: false
  multi-cluster-disabled: false
  multi-cluster-role: Spoke
  options: {}

disabled: set to false to enable the Scheduler component (default is true).
multi-cluster-disabled: when false, multi-cluster features are enabled (default is true).
multi-cluster-role: Hub or Spoke. When set to Hub, TektonConfig also creates and manages the TektonMulticlusterProxyAAE component automatically (the proxy is used to communicate with spoke clusters, e.g. for Kueue MultiKueue). On spoke clusters use Spoke; the proxy is not installed there.

See TektonMulticlusterProxyAAE for details on the proxy component and its requirements.

OpenShift: proxy-aae Kueue namespace

The proxy-aae deployment reads WORKERS_SECRET_NAMESPACE to locate the Kueue operator namespace. The Kubernetes default is kueue-system; on OpenShift the operator automatically sets this to openshift-kueue-operator. If Kueue is installed in a non-default namespace, override WORKERS_SECRET_NAMESPACE via spec.multiclusterProxyAAE.options in TektonConfig:

spec:
  multiclusterProxyAAE:
    options:
      deployments:
        proxy-aae:
          spec:
            template:
              spec:
                containers:
                - name: proxy-aae
                  env:
                  - name: WORKERS_SECRET_NAMESPACE
                    value: my-kueue-namespace

Addon

TektonAddon install some resources along with Tekton Pipelines on the cluster. This provides few PipelineTemplates, ResolverTasks, ResolverStepActions and CommunityResolverTasks.

This section allows to customize installation of those resources through params. You can read more about the supported params here.

Example:

addon:
  params:
    - name: "pipelineTemplates"
      value: "true"
    - name: "resolverTasks"
      value: "true"
    - name: "resolverStepActions"
      value: "true"
    - name: "communityResolverTasks"
      value: "true"

NOTE: TektonAddon is currently available for OpenShift Platform only. Enabling this for Kubernetes platform is in roadmap of Operator.

Hub

This is to enable/disable showing hub resources in pipeline builder of devconsole(OpenShift UI). By default, the field is not there in the config object. If you want to disable the integration, you can add the param like below in config with value false. The possible values are true and false.

Example:

hub:
  params:
    - name: enable-devconsole-integration
      value: "false"

Dashboard

Dashboard provides configuration options for the Tekton Dashboard if the specified profile value includes the Dashboard component. (E.g. all on Kubernetes)

Example:

dashboard:
  readonly: true

readonly: If set to true, install the Dashboard in read-only mode

This is an Optional section.

Resolvers

As part of TektonPipelines, resolvers are installed which are by default enabled. User can disable them through TektonConfig.

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    enable-bundles-resolver: true
    enable-cluster-resolver: true
    enable-git-resolver: true
    enable-hub-resolver: true

User can also provide resolver specific configurations through TektonConfig. The Default configurations are not added by default in TektonConfig. To override default configurations, user can provide the configurations as below. You can find the default configurations here

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    bundles-resolver-config:
      default-service-account: pipelines
    cluster-resolver-config:
      default-namespace: cluster-resolver-test
    enable-bundles-resolver: true
    enable-cluster-resolver: true
    enable-git-resolver: true
    enable-hub-resolver: true
    git-resolver-config:
      server-url: localhost.com
    hub-resolver-config:
      default-tekton-hub-catalog: tekton
      tekton-hub-api: "https://my-custom-tekton-hub.example.com"
      artifact-hub-api: "https://my-custom-artifact-hub.example.com"

Under the hub-resolver-config, the tekton-hub-api and artifact-hub-api will be passed as environment variable into tekton-pipelines-remote-resolvers controller.
In the deployment the environment name will be converted as follows,

tekton-hub-api => TEKTON_HUB_API
artifact-hub-api => ARTIFACT_HUB_API

OpenShiftPipelinesAsCode

The PipelinesAsCode section allows you to customize the Pipelines as Code features. When you change the TektonConfig CR, the Operator automatically applies the settings to custom resources and configmaps in your installation.

Some of the fields have default values, so operator will add them if the user hasn’t passed in CR. Other fields which don’t have default values unless the user specifies them. User can find those here.

Example:

platforms:
  openshift:
    pipelinesAsCode:
      additionalPACControllers:
        controllername:
          enable: true
          configMapName:
          secretName:
          settings:
      enable: true
      settings:
        application-name: Pipelines as Code CI
        auto-configure-new-github-repo: "false"
        bitbucket-cloud-check-source-ip: "true"
        custom-console-name: ""
        custom-console-url: ""
        custom-console-url-pr-details: ""
        custom-console-url-pr-tasklog: ""
        error-detection-from-container-logs: "false"
        error-detection-max-number-of-lines: "50"
        error-detection-simple-regexp:
          ^(?P<filename>[^:]*):(?P<line>[0-9]+):(?P<column>[0-9]+):([
          ]*)?(?P<error>.*)
        error-log-snippet: "true"
        enable-cancel-in-progress-on-pull-requests: "false"
        enable-cancel-in-progress-on-push: "false"
        hub-catalog-name: tekton
        hub-url: https://api.hub.tekton.dev/v1
        require-ok-to-test-sha: "false"
        remote-tasks: "true"
        secret-auto-create: "true"
        secret-github-app-token-scoped: "true"

Remote Hub Catalogs

Pipelines as Code supports configuring remote hub catalogs to fetch tasks and pipelines. You can configure custom catalogs using the catalog-{INDEX}-* settings pattern.

Each custom catalog requires the following four fields:

Field	Description	Required
`catalog-{INDEX}-id`	Unique identifier for the catalog. Users reference tasks from this catalog using this ID as prefix (e.g., `custom://task-name`)	Yes
`catalog-{INDEX}-name`	Name of the catalog within the hub	Yes
`catalog-{INDEX}-url`	URL endpoint of the hub API	Yes
`catalog-{INDEX}-type`	Type of hub: `artifacthub` (for Artifact Hub) or `tektonhub` (for Tekton Hub)	Yes

Where {INDEX} is a number that can be incremented to add multiple catalogs (e.g., 1, 2, 3).

Example: Configuring a Custom Hub Catalog

platforms:
  openshift:
    pipelinesAsCode:
      enable: true
      settings:
        catalog-1-id: "custom"
        catalog-1-name: "tekton"
        catalog-1-url: "https://api.custom.hub/v1"
        catalog-1-type: "tektonhub"

Example: Configuring Multiple Hub Catalogs

You can configure multiple hub catalogs by incrementing the catalog-{INDEX} number:

platforms:
  openshift:
    pipelinesAsCode:
      enable: true
      settings:
        catalog-1-id: "custom"
        catalog-1-name: "tekton"
        catalog-1-url: "https://api.custom.hub/v1"
        catalog-1-type: "tektonhub"
        catalog-2-id: "artifact"
        catalog-2-name: "tekton-catalog-tasks"
        catalog-2-url: "https://artifacthub.io"
        catalog-2-type: "artifacthub"

Referencing Tasks from Custom Catalogs

Once configured, users can reference tasks from custom catalogs by adding a prefix matching the catalog ID:

pipelinesascode.tekton.dev/task: "custom://git-clone"
pipelinesascode.tekton.dev/task: "artifact://buildah"

Note: Pipelines-as-Code will not try to fallback to the default or another custom hub if the task referenced is not found (the Pull Request will be set as failed).

For more details, see the Pipelines-as-Code Remote Hub Catalogs documentation.

NOTE: OpenShiftPipelinesAsCode is currently available for the OpenShift Platform only.

Event based pruner

The tektonpruner section in the TektonConfig spec allows you to manage the event-driven Tekton Pruner, which enables configuration-based cleanup of Tekton resources such as PipelineRuns and TaskRuns.

Important: This component is disabled by default. To enable the event-based pruner, the existing job-based pruner pruner MUST be disabled.

Basic Configuration

  pruner:
    disabled: true  # Must disable job-based pruner
  tektonpruner:
    disabled: false  # Enable event-based pruner
    global-config:
      enforcedConfigLevel: global  # Options: global, namespace
      ttlSecondsAfterFinished: 3600  # Delete runs older than 1 hour (optional)
      historyLimit: 100              # Keep only 100 runs total (optional)
      successfulHistoryLimit: 50     # Keep only 50 successful runs (optional)
      failedHistoryLimit: 20         # Keep only 20 failed runs (optional)
    options: {}

Configuration Levels

The enforcedConfigLevel determines the configuration hierarchy:

global: Cluster-wide defaults apply to all namespaces (no namespace overrides allowed)
namespace: Allows namespace-level overrides via ConfigMaps in individual namespaces

Pruning Fields

You can specify any combination of these fields. The pruner deletes runs when any one of the specified conditions is met:

ttlSecondsAfterFinished: Time in seconds to retain completed runs before pruning
historyLimit: Maximum number of runs to retain for each status (applies independently to both successful and failed runs)
successfulHistoryLimit: Maximum number of successful runs to retain
failedHistoryLimit: Maximum number of failed runs to retain

Note: If successfulHistoryLimit or failedHistoryLimit is not specified, historyLimit value is used as fallback for that status type.

Namespace-Level Configuration

Configure different default pruning policies for specific namespaces in the global config:

  tektonpruner:
    disabled: false
    global-config:
      enforcedConfigLevel: namespace
      historyLimit: 100  # Global default
      namespaces:
        dev-namespace:
          historyLimit: 50
          ttlSecondsAfterFinished: 1800  # 30 minutes for dev
        prod-namespace:
          successfulHistoryLimit: 200
          failedHistoryLimit: 50
          ttlSecondsAfterFinished: 86400  # 24 hours for prod

Note: For advanced configurations including resource-level selectors and per-namespace overrides via ConfigMaps, refer to the TektonPruner documentation.

Complete Example

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  targetNamespace: tekton-pipelines
  profile: all
  pruner:
    disabled: true  # Disable job-based pruner
  tektonpruner:
    disabled: false
    global-config:
      enforcedConfigLevel: namespace
      historyLimit: 100
      ttlSecondsAfterFinished: 7200  # 2 hours
      namespaces:
        tekton-pipelines:
          historyLimit: 200
          successfulHistoryLimit: 150
          failedHistoryLimit: 50
        dev:
          ttlSecondsAfterFinished: 3600  # 1 hour
          historyLimit: 50
    options:
      disabled: false
      deployments:
        tekton-pruner-controller:
          spec:
            replicas: 1

Configuration Notes:

Both pruners (job-based and event-based) cannot be enabled simultaneously
The event-based pruner responds to resource events in real-time, providing more efficient cleanup
When enforcedConfigLevel is set to namespace, individual namespaces can override these settings using ConfigMaps

Additional fields as `options`

There is a field called options available in all the components.

NOTE: There is a possibility to have two different values for a field.
An example: with a pre-defined field you can set value and the same field may be defined under options as well. In that case value from options will be final.

A sample options field,

options:
  disabled: false
  configMaps:
    config-leader-election: # name of the configMap
      data:
        lease-duration: "90s"
    pipeline-config-logging: # creates new configMap under targetNamespace
      metadata:
        labels:
          my-custom-logger: "true"
        annotations:
          logger-type: "uber-zap"
      data:
        loglevel.controller: "info"
        loglevel.webhook: "info"
        zap-logger-config: |
          {
            "level": "debug",
            "development": false,
            "sampling": {
              "initial": 100,
              "thereafter": 50
            },
            "outputPaths": ["stdout"],
            "errorOutputPaths": ["stderr"],
            "encoding": "json",
            "encoderConfig": {
              "timeKey": "ts",
              "levelKey": "severity",
              "nameKey": "logger",
              "callerKey": "caller",
              "messageKey": "message",
              "stacktraceKey": "stacktrace",
              "lineEnding": "",
              "levelEncoder": "",
              "timeEncoder": "iso8601",
              "durationEncoder": "",
              "callerEncoder": ""
            }
          }          

  deployments:
    tekton-pipelines-controller: # name of the deployment
      metadata:
        labels:
          custom-label: "foo"
        annotations:
          custom-annotation: "foo"
      spec:
        replicas: 2
        template:
          spec:
            containers:
              - name: tekton-pipelines-controller
                env:
                  - name: CONFIG_LOGGING_NAME
                    value: pipeline-config-logging
  statefulSets:
    web: # name of the statefulSets
      metadata:
        labels:
          custom-label: foo
        annotations:
          custom-annotation: foo
      spec:
        replicas: 3
        template:
          spec:
            containers:
              - name: nginx
                env:
                  - name: NGINX_MODE
                    value: production
  horizontalPodAutoscalers:
    tekton-pipelines-webhook: # name of the hpa
      metadata:
        annotations:
        labels:
      spec:
        minReplicas: 2
        maxReplicas: 7
        metrics:
          - resource:
              name: cpu
              target:
                averageUtilization: 85
                type: Utilization
            type: Resource
  webhookConfigurationOptions:
    validation.webhook.pipeline.tekton.dev:
      failurePolicy: Fail
      timeoutSeconds: 20
      sideEffects: None
    webhook.pipeline.tekton.dev:
      failurePolicy: Fail
      timeoutSeconds: 20
      sideEffects: None

disabled - disables the additional options support, if disabled set to true. default: false

ConfigMaps

Supports to update existing configMap also supports to create new configMap.

The following fields are supported in configMap

metadata
- labels - supports add and update
- annotations - supports add and update
data - supports add and update

Deployments

Supports to update the existing deployments. But not supported to create new deployment.

The following fields are supported in deployment

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- replicas - updates deployment replicas count
- template
  - metadata
    - labels - supports add and update
    - annotations - supports add and update
  - spec
    - affinity - replaces the existing Affinity with this, if not empty
    - priorityClassName - replaces the existing PriorityClassName with this, if not empty
    - nodeSelector - replaces the existing NodeSelector with this, if not empty
    - tolerations - replaces the existing tolerations with this, if not empty
    - topologySpreadConstraints - replaces the existing TopologySpreadConstraints with this, if not empty
    - runtimeClassName - adds and updates runtimeClassName
    - volumes - adds and updates volumes
    - initContainers - adds and updates init-containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS
    - containers - adds and updates containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS

StatefulSets

Supports to update the existing StatefulSet. But not supported to create new StatefulSet.

The following fields are supported in StatefulSet

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- replicas - updates statefulSets replicas count
- serviceName - updates service name
- podManagementPolicy - updates pod management policy
- volumeClaimTemplates - updates volume claim templates
- template
  - metadata
    - labels - supports add and update
    - annotations - supports add and update
  - spec
    - affinity - replaces the existing Affinity with this, if not empty
    - priorityClassName - replaces the existing PriorityClassName with this, if not empty
    - nodeSelector - replaces the existing NodeSelector with this, if not empty
    - tolerations - replaces the existing tolerations with this, if not empty
    - topologySpreadConstraints - replaces the existing TopologySpreadConstraints with this, if not empty
    - runtimeClassName - adds and updates runtimeClassName
    - volumes - adds and updates volumes
    - initContainers - adds and updates init-containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS
    - containers - adds and updates containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS

HorizontalPodAutoscalers

Supports to update the existing HorizontalPodAutoscaler(HPA) also supports to create new HPA.

The following fields are supported in HorizontalPodAutoscaler (aka HPA)

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- scaleTargetRef - replaces scaleTargetRef with this, if kind and name are not empty
- minReplicas - updates minimum replicas count
- maxReplicas - updates maximum replicas count
- metrics - replaces the metrics details with this array, if not empty
- behavior - updates behavior data with this, if not empty
  - scaleUp - replaces scaleUp with this, if not empty
  - scaleDown - replaces scaleDown with this, if not empty

NOTE: If a Deployment or StatefulSet has a Horizontal Pod Autoscaling (HPA) and is in active state, Operator will not control the replicas to that resource. However if status.desiredReplicas and spec.minReplicas not present in HPA, operator takes the control. Also if HPA disabled, operator takes control. Even though the operator takes the control, the replicas value will be adjusted to the hpa’s scaling range.

webhookConfigurationOptions

Defines additional options for each webhooks. Use webhook name as a key to define options for a webhook. Options are ignored if the webhook does not exist with the name key. To get detailed information about webhooks options visit https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/

the following options are supported for webhookConfigurationOptions

failurePolicy - defines how unrecognized errors and timeout errors from the admission webhook are handled. Allowed values are Ignore or Fail
timeoutSeconds - allows configuring how long the API server should wait for a webhook to respond before treating the call as a failure.
sideEffects - indicates whether the webhook have a side effet. Allowed values are None, NoneOnDryRun, Unknown, or Some

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Config

TektonConfig custom resource is the top most component of the operator which allows user to install and customize all other components at a single place.

Operator provides support for installing and managing following operator components through TektonConfig:

Other than the above components depending on the platform operator also provides support for

On both Kubernetes and OpenShift
- TektonChain
- TektonResult
On Kubernetes
- TektonDashboard
- OpenShiftPipelinesAsCode (installed via spec.platforms.kubernetes.pipelinesAsCode; same CRD/kind as on OpenShift)
On OpenShift
- TektonAddon
- OpenShiftPipelinesAsCode
When scheduler multi-cluster is enabled with Hub role (both Kubernetes and OpenShift)
- TektonMulticlusterProxyAAE

The TektonConfig CR provides the following features

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  targetNamespace: tekton-pipelines
  targetNamespaceMetadata:
    labels: {}
    annotations: {}
  profile: all
  config:
    nodeSelector: <>
    tolerations: []
    priorityClassName: system-cluster-critical
  chain:
    disabled: false
  pipeline:
    await-sidecar-readiness: true
    coschedule: workspaces
    disable-creds-init: false
    disable-home-env-overwrite: true
    disable-working-directory-overwrite: true
    disable-inline-spec: "pipeline,pipelinerun,taskrun"
    enable-api-fields: beta
    enable-bundles-resolver: true
    enable-cel-in-whenexpression: false
    enable-cluster-resolver: true
    enable-custom-tasks: true
    enable-git-resolver: true
    enable-hub-resolver: true
    enable-param-enum: false
    enable-provenance-in-status: true
    enable-step-actions: false
    enforce-nonfalsifiability: none
    keep-pod-on-cancel: false
    max-result-size: 4096
    metrics.count.enable-reason: false
    metrics.pipelinerun.duration-type: histogram
    metrics.pipelinerun.level: pipeline
    metrics.taskrun.duration-type: histogram
    metrics.taskrun.level: task
    # Tracing configuration (optional)
    # traces.enabled: true
    # traces.endpoint: "http://jaeger-collector.jaeger.svc.cluster.local:4318/v1/traces"
    # traces.credentialsSecret: ""
    require-git-ssh-secret-known-hosts: false
    results-from: termination-message
    running-in-environment-with-injected-sidecars: true
    send-cloudevents-for-runs: false
    set-security-context: false
    trusted-resources-verification-no-match-policy: ignore
    performance:
      disable-ha: false
      buckets: 1
      replicas: 1
      threads-per-controller: 2
      kube-api-qps: 5.0
      kube-api-burst: 10
    options:
      disabled: false
      configMaps: {}
      deployments: {}
      webhookConfigurationOptions: {}
  pruner:
    disabled: false
    schedule: "0 8 * * *"
    resources:
      - taskrun
      - pipelinerun
    keep: 3
    # keep-since: 1440
    # NOTE: you can use either "keep" or "keep-since", not both
    prune-per-resource: true
  hub:
    params:
      - name: enable-devconsole-integration
        value: "true"
    options:
      disabled: false
      configMaps: {}
      deployments: {}
      webhookConfigurationOptions: {}
  dashboard:
    readonly: true
    options:
      disabled: false
      configMaps: {}
      deployments: {}
      webhookConfigurationOptions: {}
  result:
    disabled: false
    is_external_db: false
    options: {}
    performance:
      disable-ha: false
      buckets: 1
      replicas: 1
  trigger:
    disabled: false
platforms:
    openshift:   # or `kubernetes:` on Kubernetes clusters
      pipelinesAsCode:
        additionalPACControllers:
          <controllerName>:
            enable: true
            configMapName:
            secretName:
            settings:
        enable: true
        settings:
          application-name: Pipelines as Code CI
          auto-configure-new-github-repo: "false"
          bitbucket-cloud-check-source-ip: "true"
          custom-console-name: ""
          custom-console-url: ""
          custom-console-url-pr-details: ""
          custom-console-url-pr-tasklog: ""
          error-detection-from-container-logs: "false"
          error-detection-max-number-of-lines: "50"
          error-detection-simple-regexp:
            ^(?P<filename>[^:]*):(?P<line>[0-9]+):(?P<column>[0-9]+):([
            ]*)?(?P<error>.*)
          error-log-snippet: "true"
          error-log-snippet-number-of-lines: "3"
          enable-cancel-in-progress-on-pull-requests: "false"
          enable-cancel-in-progress-on-push: "false"
          hub-catalog-name: tekton
          hub-url: https://api.hub.tekton.dev/v1
          require-ok-to-test-sha: "false"
          skip-push-event-for-pr-commits: "true"
          remote-tasks: "true"
          secret-auto-create: "true"
          secret-github-app-token-scoped: "true"
      options:
        disabled: false
        configMaps: {}
        deployments: {}
        webhookConfigurationOptions: {}

Look for the particular section to understand a particular field in the spec.

Target Namespace

This allows user to choose a namespace to install the Tekton Components such as pipelines, triggers.

By default, namespace would be tekton-pipelines for Kubernetes and openshift-pipelines for OpenShift.

Note: Namespace openshift-operators is not allowed in OpenShift as a targetNamespace.

Target Namespace Metadata

targetNamespaceMetadata allows user to add their custom labels and annotations to the target namespace via TektonConfig CR.

Profile

This allows user to choose which all components to install on the cluster. There are 3 profiles available:

all: This profile will install all components (TektonPipeline, TektonTrigger, TektonResult and TektonChain)
basic: This profile will install only TektonPipeline, TektonTrigger, TektonResult and TektonChain component
lite: This profile will install only TektonPipeline component

On Kubernetes, all profile will install TektonDashboard and on OpenShift TektonAddon will be installed.

Config

Config provides fields to configure deployments created by the Operator. This provides following fields:

User can pass the required fields and this would be passed to all Operator components which will get added in all deployments created by Operator.

Example:

config:
  nodeSelector:
    key: value
  tolerations:
    - key: "key1"
      operator: "Equal"
      value: "value1"
      effect: "NoSchedule"
  priorityClassName: system-node-critical

This is an Optional section.

NOTE: If spec.config.priorityClassName is used, then the required priorityClass is expected to be created by the user to get the Tekton resources pods in running state

Pipeline

Pipeline section allows user to customize the Tekton pipeline features. This allow user to customize the values in configmaps.

Refer to properties section in TektonPipeline for available options.

Example:

pipeline:
  disable-creds-init: false
  disable-home-env-overwrite: true
  disable-working-directory-overwrite: true
  enable-api-fields: stable
  enable-custom-tasks: false
  metrics.pipelinerun.duration-type: histogram
  metrics.pipelinerun.level: pipelinerun
  metrics.taskrun.duration-type: histogram
  metrics.taskrun.level: taskrun
  traces.enabled: true
  traces.endpoint: "http://jaeger-collector.jaeger.svc.cluster.local:4318/v1/traces"
  traces.credentialsSecret: "" # optional
  require-git-ssh-secret-known-hosts: false
  running-in-environment-with-injected-sidecars: true
  trusted-resources-verification-no-match-policy: ignore
  performance:
    replicas: 1
    disable-ha: false
    buckets: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10

Chain

Chain section allows user to customize the Tekton Chain features. This allows user to customize the values in configmaps

Refer to properties section in TektonChain for available options

Example:

chain:
  disabled: false # - `disabled` : if the value set as `true`, chains feature will be disabled (default: `false`)
  targetNamespace: tekton-pipelines
  generateSigningSecret: true # default value: false
  controllerEnvs:
    - name: MONGO_SERVER_URL # This is the only field supported at the moment which is optional and when added by user, it is added as env to Chains controller
      value: #value               # This can be provided same as env field of container
  artifacts.taskrun.format: in-toto
  artifacts.taskrun.storage: tekton,oci (comma separated values)
  artifacts.taskrun.signer: x509
  artifacts.oci.storage: oci (comma separated values)
  artifacts.oci.format: simplesigning
  artifacts.oci.signer: x509
  artifacts.pipelinerun.format: in-toto
  artifacts.pipelinerun.storage: tekton,oci (comma separated values)
  artifacts.pipelinerun.signer: x509
  storage.gcs.bucket: #value
  storage.oci.repository: #value
  storage.oci.repository.insecure: #value (boolean - true/false)
  storage.docdb.url: #value
  storage.grafeas.projectid: #value
  storage.grafeas.noteid: #value
  storage.grafeas.notehint: #value
  builder.id: #value
  signers.x509.fulcio.enabled: #value (boolean - true/false)
  signers.x509.fulcio.address: #value
  signers.x509.fulcio.issuer: #value
  signers.x509.fulcio.provider: #value
  signers.x509.identity.token.file: #value
  signers.x509.tuf.mirror.url: #value
  signers.kms.kmsref: #value
  signers.kms.kmsref.auth.address: #value
  signers.kms.kmsref.auth.token: #value
  signers.kms.kmsref.auth.oidc.path: #value
  signers.kms.kmsref.auth.oidc.role: #value
  signers.kms.kmsref.auth.spire.sock: #value
  signers.kms.kmsref.auth.spire.audience: #value
  transparency.enabled: #value (boolean - true/false)
  transparency.url: #value

Result

Result section allows user to customize the Tekton Result component, Refer to Result Spec section in TektonResult for available options.

Default Result configuration in TektonConfig looks like following if user doesn’t specified any configuration options

Example:

result:
  disabled: false
  is_external_db: false
  options: {}

User can customize Result configuration with following options

Example:

result:
  disabled: false # - `disabled` : if the value set as `true`, result component will be disabled (default: `false`)
  targetNamespace: tekton-pipelines
  is_external_db: false # By default, this is set to false, TektonOperator will create Tekton Results database. If set to true, an external database will be used, and Tekton Results will retrieve its database credentials from the Kubernetes secret named tekton-results-postgres
  db_host: localhost
  db_port: 5342
  db_sslmode: verify-full
  db_sslrootcert: /etc/tls/db/ca.crt
  db_enable_auto_migration: true
  log_level: debug
  logs_api: true
  logs_type: File
  logs_buffer_size: 90kb
  logs_path: /logs
  auth_disable: true
  logging_pvc_name: tekton-logs
  secret_name: # optional
  gcs_creds_secret_name: <value>
  gcc_creds_secret_key: <value>
  gcs_bucket_name: <value>
  loki_stack_name: #optional
  loki_stack_namespace: #optional
  prometheus_port: 9090
  prometheus_histogram: false

User can configure custom database secret name for internal/external database via Tekton Config CR.

Example:

result:
  db_secret_name: # custom database secret name
  db_secret_user_key: # optional: required if custom database secret user key is not "POSTGRES_USER"
  db_secret_password_key: # optional: required if custom database secret password key is not "POSTGRES_PASSWORD"

Pruner

Pruner provides auto clean up feature for the Tekton pipelinerun and taskrun resources. In the background pruner container runs tkn command.

Example:

pruner:
  disabled: false
  schedule: "0 8 * * *"
  startingDeadlineSeconds: 100 # optional
  resources:
    - taskrun
    - pipelinerun
  keep: 3
  # keep-since: 1440
  # NOTE: you can use either "keep" or "keep-since", not both
  prune-per-resource: true

disabled : if the value set as true, pruner feature will be disabled (default: false)
schedule: how often to run the pruner job. User can understand the schedule syntax here.
startingDeadlineSeconds: Optional deadline in seconds for starting the job if it misses scheduled time for any reason. Missed jobs executions will be counted as failed ones
resources: supported resources for auto prune are taskrun and pipelinerun
keep: maximum number of resources to keep while deleting or removing resources
keep-since: retain the resources younger than the specified value in minutes
prune-per-resource: if the value set as true (default value false), the keep applied to each resource. The resources(pipeline and/or task) taken dynamically from that namespace and applied.
example: in a namespace ns-1 I have two pipeline, named pipeline-1 and pipeline-2, the out come would be: tkn pipelinerun delete --pipeline=my-pipeline-1 --keep=3 --namespace=ns-1, tkn pipelinerun delete --pipeline=my-pipeline-2 --keep=3 --namespace=ns-1. the same way works for task too.
We do not see any benefit by enabling prune-per-resource=true, when you use keep-since. As keep-since is limiting the resources by time(irrespective of resource count), there is no change on the outcome.

Note:

if disabled: false and schedule: with empty value, global pruner job will be disabled. however, if there is a prune schedule (operator.tekton.dev/prune.schedule) annotation present with a value in a namespace. a namespace wide pruner jobs will be created.

Pruner Namespace annotations

operator.tekton.dev/prune.skip - pruner job will be skipped to a namespace, if the value set as true
operator.tekton.dev/prune.schedule - pruner job will be created on a specific schedule
operator.tekton.dev/prune.keep - maximum number of resources will be kept
operator.tekton.dev/prune.keep-since - retain the resources younger than the specified value in minutes
operator.tekton.dev/prune.prune-per-resource - the keep or keep-since applied to each resource
operator.tekton.dev/prune.resources - can be taskrun and/or pipelinerun, both value can be specified with comma separated. example: taskrun,pipelinerun
operator.tekton.dev/prune.strategy - allowed values: either keep or keep-since

Note:

if a global value is not present the following values will be consider as default value
> resources: pipelinerun
> keep: 100

Scheduler

Hub cluster

scheduler:
  disabled: false
  multi-cluster-disabled: false
  multi-cluster-role: Hub
  options: {}

Spoke cluster

scheduler:
  disabled: false
  multi-cluster-disabled: false
  multi-cluster-role: Spoke
  options: {}

disabled: set to false to enable the Scheduler component (default is true).
multi-cluster-disabled: when false, multi-cluster features are enabled (default is true).
multi-cluster-role: Hub or Spoke. When set to Hub, TektonConfig also creates and manages the TektonMulticlusterProxyAAE component automatically (the proxy is used to communicate with spoke clusters, e.g. for Kueue MultiKueue). On spoke clusters use Spoke; the proxy is not installed there.

See TektonMulticlusterProxyAAE for details on the proxy component and its requirements.

OpenShift: proxy-aae Kueue namespace

spec:
  multiclusterProxyAAE:
    options:
      deployments:
        proxy-aae:
          spec:
            template:
              spec:
                containers:
                - name: proxy-aae
                  env:
                  - name: WORKERS_SECRET_NAMESPACE
                    value: my-kueue-namespace

Addon

TektonAddon install some resources along with Tekton Pipelines on the cluster. This provides few PipelineTemplates, ResolverTasks, ResolverStepActions and CommunityResolverTasks.

This section allows to customize installation of those resources through params. You can read more about the supported params here.

Example:

addon:
  params:
    - name: "pipelineTemplates"
      value: "true"
    - name: "resolverTasks"
      value: "true"
    - name: "resolverStepActions"
      value: "true"
    - name: "communityResolverTasks"
      value: "true"

NOTE: TektonAddon is currently available for OpenShift Platform only. Enabling this for Kubernetes platform is in roadmap of Operator.

Hub

Example:

hub:
  params:
    - name: enable-devconsole-integration
      value: "false"

Dashboard

Dashboard provides configuration options for the Tekton Dashboard if the specified profile value includes the Dashboard component. (E.g. all on Kubernetes)

Example:

dashboard:
  readonly: true

readonly: If set to true, install the Dashboard in read-only mode

This is an Optional section.

Resolvers

As part of TektonPipelines, resolvers are installed which are by default enabled. User can disable them through TektonConfig.

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    enable-bundles-resolver: true
    enable-cluster-resolver: true
    enable-git-resolver: true
    enable-hub-resolver: true

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    bundles-resolver-config:
      default-service-account: pipelines
    cluster-resolver-config:
      default-namespace: cluster-resolver-test
    enable-bundles-resolver: true
    enable-cluster-resolver: true
    enable-git-resolver: true
    enable-hub-resolver: true
    git-resolver-config:
      server-url: localhost.com
    hub-resolver-config:
      default-tekton-hub-catalog: tekton
      tekton-hub-api: "https://my-custom-tekton-hub.example.com"
      artifact-hub-api: "https://my-custom-artifact-hub.example.com"

tekton-hub-api => TEKTON_HUB_API
artifact-hub-api => ARTIFACT_HUB_API

OpenShiftPipelinesAsCode

The PipelinesAsCode section allows you to customize the Pipelines as Code features on both Kubernetes and OpenShift. When you change the TektonConfig CR, the Operator automatically applies the settings to custom resources and configmaps in your installation. On Kubernetes, configure spec.platforms.kubernetes.pipelinesAsCode (the managed CR remains OpenShiftPipelinesAsCode for API compatibility).

Example:

platforms:
  openshift:   # or `kubernetes:`
    pipelinesAsCode:
      additionalPACControllers:
        controllername:
          enable: true
          configMapName:
          secretName:
          settings:
      enable: true
      settings:
        application-name: Pipelines as Code CI
        auto-configure-new-github-repo: "false"
        bitbucket-cloud-check-source-ip: "true"
        custom-console-name: ""
        custom-console-url: ""
        custom-console-url-pr-details: ""
        custom-console-url-pr-tasklog: ""
        error-detection-from-container-logs: "false"
        error-detection-max-number-of-lines: "50"
        error-detection-simple-regexp:
          ^(?P<filename>[^:]*):(?P<line>[0-9]+):(?P<column>[0-9]+):([
          ]*)?(?P<error>.*)
        error-log-snippet: "true"
        enable-cancel-in-progress-on-pull-requests: "false"
        enable-cancel-in-progress-on-push: "false"
        hub-catalog-name: tekton
        hub-url: https://api.hub.tekton.dev/v1
        require-ok-to-test-sha: "false"
        remote-tasks: "true"
        secret-auto-create: "true"
        secret-github-app-token-scoped: "true"

Remote Hub Catalogs

Pipelines as Code supports configuring remote hub catalogs to fetch tasks and pipelines. You can configure custom catalogs using the catalog-{INDEX}-* settings pattern.

Each custom catalog requires the following four fields:

Field	Description	Required
`catalog-{INDEX}-id`	Unique identifier for the catalog. Users reference tasks from this catalog using this ID as prefix (e.g., `custom://task-name`)	Yes
`catalog-{INDEX}-name`	Name of the catalog within the hub	Yes
`catalog-{INDEX}-url`	URL endpoint of the hub API	Yes
`catalog-{INDEX}-type`	Type of hub: `artifacthub` (for Artifact Hub) or `tektonhub` (for Tekton Hub)	Yes

Where {INDEX} is a number that can be incremented to add multiple catalogs (e.g., 1, 2, 3).

Example: Configuring a Custom Hub Catalog

platforms:
  openshift:
    pipelinesAsCode:
      enable: true
      settings:
        catalog-1-id: "custom"
        catalog-1-name: "tekton"
        catalog-1-url: "https://api.custom.hub/v1"
        catalog-1-type: "tektonhub"

Example: Configuring Multiple Hub Catalogs

You can configure multiple hub catalogs by incrementing the catalog-{INDEX} number:

platforms:
  openshift:
    pipelinesAsCode:
      enable: true
      settings:
        catalog-1-id: "custom"
        catalog-1-name: "tekton"
        catalog-1-url: "https://api.custom.hub/v1"
        catalog-1-type: "tektonhub"
        catalog-2-id: "artifact"
        catalog-2-name: "tekton-catalog-tasks"
        catalog-2-url: "https://artifacthub.io"
        catalog-2-type: "artifacthub"

Referencing Tasks from Custom Catalogs

Once configured, users can reference tasks from custom catalogs by adding a prefix matching the catalog ID:

pipelinesascode.tekton.dev/task: "custom://git-clone"
pipelinesascode.tekton.dev/task: "artifact://buildah"

Note: Pipelines-as-Code will not try to fallback to the default or another custom hub if the task referenced is not found (the Pull Request will be set as failed).

For more details, see the Pipelines-as-Code Remote Hub Catalogs documentation.

NOTE: On Kubernetes clusters, use spec.platforms.kubernetes.pipelinesAsCode. The custom resource kind remains OpenShiftPipelinesAsCode.

Event based pruner

Important: This component is disabled by default. To enable the event-based pruner, the existing job-based pruner pruner MUST be disabled.

Basic Configuration

  pruner:
    disabled: true  # Must disable job-based pruner
  tektonpruner:
    disabled: false  # Enable event-based pruner
    global-config:
      enforcedConfigLevel: global  # Options: global, namespace
      ttlSecondsAfterFinished: 3600  # Delete runs older than 1 hour (optional)
      historyLimit: 100              # Keep only 100 runs total (optional)
      successfulHistoryLimit: 50     # Keep only 50 successful runs (optional)
      failedHistoryLimit: 20         # Keep only 20 failed runs (optional)
    options: {}

Configuration Levels

The enforcedConfigLevel determines the configuration hierarchy:

global: Cluster-wide defaults apply to all namespaces (no namespace overrides allowed)
namespace: Allows namespace-level overrides via ConfigMaps in individual namespaces

Pruning Fields

You can specify any combination of these fields. The pruner deletes runs when any one of the specified conditions is met:

ttlSecondsAfterFinished: Time in seconds to retain completed runs before pruning
historyLimit: Maximum number of runs to retain for each status (applies independently to both successful and failed runs)
successfulHistoryLimit: Maximum number of successful runs to retain
failedHistoryLimit: Maximum number of failed runs to retain

Note: If successfulHistoryLimit or failedHistoryLimit is not specified, historyLimit value is used as fallback for that status type.

Namespace-Level Configuration

Configure different default pruning policies for specific namespaces in the global config:

  tektonpruner:
    disabled: false
    global-config:
      enforcedConfigLevel: namespace
      historyLimit: 100  # Global default
      namespaces:
        dev-namespace:
          historyLimit: 50
          ttlSecondsAfterFinished: 1800  # 30 minutes for dev
        prod-namespace:
          successfulHistoryLimit: 200
          failedHistoryLimit: 50
          ttlSecondsAfterFinished: 86400  # 24 hours for prod

Note: For advanced configurations including resource-level selectors and per-namespace overrides via ConfigMaps, refer to the TektonPruner documentation.

Complete Example

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  targetNamespace: tekton-pipelines
  profile: all
  pruner:
    disabled: true  # Disable job-based pruner
  tektonpruner:
    disabled: false
    global-config:
      enforcedConfigLevel: namespace
      historyLimit: 100
      ttlSecondsAfterFinished: 7200  # 2 hours
      namespaces:
        tekton-pipelines:
          historyLimit: 200
          successfulHistoryLimit: 150
          failedHistoryLimit: 50
        dev:
          ttlSecondsAfterFinished: 3600  # 1 hour
          historyLimit: 50
    options:
      disabled: false
      deployments:
        tekton-pruner-controller:
          spec:
            replicas: 1

Configuration Notes:

Both pruners (job-based and event-based) cannot be enabled simultaneously
The event-based pruner responds to resource events in real-time, providing more efficient cleanup
When enforcedConfigLevel is set to namespace, individual namespaces can override these settings using ConfigMaps

Additional fields as `options`

There is a field called options available in all the components.

NOTE: There is a possibility to have two different values for a field.
An example: with a pre-defined field you can set value and the same field may be defined under options as well. In that case value from options will be final.

A sample options field,

options:
  disabled: false
  configMaps:
    config-leader-election: # name of the configMap
      data:
        lease-duration: "90s"
    pipeline-config-logging: # creates new configMap under targetNamespace
      metadata:
        labels:
          my-custom-logger: "true"
        annotations:
          logger-type: "uber-zap"
      data:
        loglevel.controller: "info"
        loglevel.webhook: "info"
        zap-logger-config: |
          {
            "level": "debug",
            "development": false,
            "sampling": {
              "initial": 100,
              "thereafter": 50
            },
            "outputPaths": ["stdout"],
            "errorOutputPaths": ["stderr"],
            "encoding": "json",
            "encoderConfig": {
              "timeKey": "ts",
              "levelKey": "severity",
              "nameKey": "logger",
              "callerKey": "caller",
              "messageKey": "message",
              "stacktraceKey": "stacktrace",
              "lineEnding": "",
              "levelEncoder": "",
              "timeEncoder": "iso8601",
              "durationEncoder": "",
              "callerEncoder": ""
            }
          }          

  deployments:
    tekton-pipelines-controller: # name of the deployment
      metadata:
        labels:
          custom-label: "foo"
        annotations:
          custom-annotation: "foo"
      spec:
        replicas: 2
        template:
          spec:
            containers:
              - name: tekton-pipelines-controller
                env:
                  - name: CONFIG_LOGGING_NAME
                    value: pipeline-config-logging
  statefulSets:
    web: # name of the statefulSets
      metadata:
        labels:
          custom-label: foo
        annotations:
          custom-annotation: foo
      spec:
        replicas: 3
        template:
          spec:
            containers:
              - name: nginx
                env:
                  - name: NGINX_MODE
                    value: production
  horizontalPodAutoscalers:
    tekton-pipelines-webhook: # name of the hpa
      metadata:
        annotations:
        labels:
      spec:
        minReplicas: 2
        maxReplicas: 7
        metrics:
          - resource:
              name: cpu
              target:
                averageUtilization: 85
                type: Utilization
            type: Resource
  webhookConfigurationOptions:
    validation.webhook.pipeline.tekton.dev:
      failurePolicy: Fail
      timeoutSeconds: 20
      sideEffects: None
    webhook.pipeline.tekton.dev:
      failurePolicy: Fail
      timeoutSeconds: 20
      sideEffects: None

disabled - disables the additional options support, if disabled set to true. default: false

ConfigMaps

Supports to update existing configMap also supports to create new configMap.

The following fields are supported in configMap

metadata
- labels - supports add and update
- annotations - supports add and update
data - supports add and update

Deployments

Supports to update the existing deployments. But not supported to create new deployment.

The following fields are supported in deployment

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- replicas - updates deployment replicas count
- template
  - metadata
    - labels - supports add and update
    - annotations - supports add and update
  - spec
    - affinity - replaces the existing Affinity with this, if not empty
    - priorityClassName - replaces the existing PriorityClassName with this, if not empty
    - nodeSelector - replaces the existing NodeSelector with this, if not empty
    - tolerations - replaces the existing tolerations with this, if not empty
    - topologySpreadConstraints - replaces the existing TopologySpreadConstraints with this, if not empty
    - runtimeClassName - adds and updates runtimeClassName
    - volumes - adds and updates volumes
    - initContainers - adds and updates init-containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS
    - containers - adds and updates containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS

StatefulSets

Supports to update the existing StatefulSet. But not supported to create new StatefulSet.

The following fields are supported in StatefulSet

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- replicas - updates statefulSets replicas count
- serviceName - updates service name
- podManagementPolicy - updates pod management policy
- volumeClaimTemplates - updates volume claim templates
- template
  - metadata
    - labels - supports add and update
    - annotations - supports add and update
  - spec
    - affinity - replaces the existing Affinity with this, if not empty
    - priorityClassName - replaces the existing PriorityClassName with this, if not empty
    - nodeSelector - replaces the existing NodeSelector with this, if not empty
    - tolerations - replaces the existing tolerations with this, if not empty
    - topologySpreadConstraints - replaces the existing TopologySpreadConstraints with this, if not empty
    - runtimeClassName - adds and updates runtimeClassName
    - volumes - adds and updates volumes
    - initContainers - adds and updates init-containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS
    - containers - adds and updates containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS

HorizontalPodAutoscalers

Supports to update the existing HorizontalPodAutoscaler(HPA) also supports to create new HPA.

The following fields are supported in HorizontalPodAutoscaler (aka HPA)

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- scaleTargetRef - replaces scaleTargetRef with this, if kind and name are not empty
- minReplicas - updates minimum replicas count
- maxReplicas - updates maximum replicas count
- metrics - replaces the metrics details with this array, if not empty
- behavior - updates behavior data with this, if not empty
  - scaleUp - replaces scaleUp with this, if not empty
  - scaleDown - replaces scaleDown with this, if not empty

webhookConfigurationOptions

the following options are supported for webhookConfigurationOptions

failurePolicy - defines how unrecognized errors and timeout errors from the admission webhook are handled. Allowed values are Ignore or Fail
timeoutSeconds - allows configuring how long the API server should wait for a webhook to respond before treating the call as a failure.
sideEffects - indicates whether the webhook have a side effet. Allowed values are None, NoneOnDryRun, Unknown, or Some

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Config

TektonConfig custom resource is the top most component of the operator which allows user to install and customize all other components at a single place.

Operator provides support for installing and managing following operator components through TektonConfig:

Other than the above components depending on the platform operator also provides support for

On both Kubernetes and OpenShift
- TektonChain
On Kubernetes
- TektonDashboard
On OpenShift
- TektonAddon
- OpenShiftPipelinesAsCode

The TektonConfig CR provides the following features

  apiVersion: operator.tekton.dev/v1alpha1
  kind: TektonConfig
  metadata:
    name: config
  spec:
    targetNamespace: tekton-pipelines
    targetNamespaceMetadata:
      labels: {}
      annotations: {}
    profile: all
    config:
      nodeSelector: <>
      tolerations: []
      priorityClassName: system-cluster-critical
    chain:
      disabled: false
    pipeline:
      await-sidecar-readiness: true
      coschedule: workspaces
      disable-affinity-assistant: false
      disable-creds-init: false
      disable-home-env-overwrite: true
      disable-working-directory-overwrite: true
      disable-inline-spec: "pipeline,pipelinerun,taskrun"
      enable-api-fields: beta
      enable-bundles-resolver: true
      enable-cel-in-whenexpression: false
      enable-cluster-resolver: true
      enable-custom-tasks: true
      enable-git-resolver: true
      enable-hub-resolver: true
      enable-param-enum: false
      enable-provenance-in-status: true
      enable-step-actions: false
      enforce-nonfalsifiability: none
      keep-pod-on-cancel: false
      max-result-size: 4096
      metrics.count.enable-reason: false
      metrics.pipelinerun.duration-type: histogram
      metrics.pipelinerun.level: pipeline
      metrics.taskrun.duration-type: histogram
      metrics.taskrun.level: task
      require-git-ssh-secret-known-hosts: false
      results-from: termination-message
      running-in-environment-with-injected-sidecars: true
      send-cloudevents-for-runs: false
      set-security-context: false
      trusted-resources-verification-no-match-policy: ignore
      performance:
        disable-ha: false
        buckets: 1
        replicas: 1
        threads-per-controller: 2
        kube-api-qps: 5.0
        kube-api-burst: 10
      options:
        disabled: false
        configMaps: {}
        deployments: {}
        webhookConfigurationOptions: {}
    pruner:
      disabled: false
      schedule: "0 8 * * *"
      resources:
        - taskrun
        - pipelinerun
      keep: 3
      # keep-since: 1440
      # NOTE: you can use either "keep" or "keep-since", not both
      prune-per-resource: true
    hub:
      params:
        - name: enable-devconsole-integration
          value: "true"
      options:
        disabled: false
        configMaps: {}
        deployments: {}
        webhookConfigurationOptions: {}
    dashboard:
      readonly: true
      options:
        disabled: false
        configMaps: {}
        deployments: {}
        webhookConfigurationOptions: {}
    platforms:
      openshift:
        pipelinesAsCode:
          additionalPACControllers:
            <controllerName>:
              enable: true
              configMapName:
              secretName:
              settings:
          enable: true
          settings:
            application-name: Pipelines as Code CI
            auto-configure-new-github-repo: "false"
            bitbucket-cloud-check-source-ip: "true"
            custom-console-name: ""
            custom-console-url: ""
            custom-console-url-pr-details: ""
            custom-console-url-pr-tasklog: ""
            error-detection-from-container-logs: "false"
            error-detection-max-number-of-lines: "50"
            error-detection-simple-regexp: ^(?P<filename>[^:]*):(?P<line>[0-9]+):(?P<column>[0-9]+):([
              ]*)?(?P<error>.*)
            error-log-snippet: "true"
            hub-catalog-name: tekton
            hub-url: https://api.hub.tekton.dev/v1
            remote-tasks: "true"
            secret-auto-create: "true"
            secret-github-app-token-scoped: "true"
        options:
          disabled: false
          configMaps: {}
          deployments: {}
          webhookConfigurationOptions: {}

Look for the particular section to understand a particular field in the spec.

Target Namespace

This allows user to choose a namespace to install the Tekton Components such as pipelines, triggers.

By default, namespace would be tekton-pipelines for Kubernetes and openshift-pipelines for OpenShift.

Note: Namespace openshift-operators is not allowed in OpenShift as a targetNamespace.

Target Namespace Metadata

targetNamespaceMetadata allows user to add their custom labels and annotations to the target namespace via TektonConfig CR.

Profile

This allows user to choose which all components to install on the cluster. There are 3 profiles available:

all: This profile will install all components (TektonPipeline, TektonTrigger and TektonChain)
basic: This profile will install only TektonPipeline, TektonTrigger and TektonChain component
lite: This profile will install only TektonPipeline component

On Kubernetes, all profile will install TektonDashboard and on OpenShift TektonAddon will be installed.

Config

Config provides fields to configure deployments created by the Operator. This provides following fields:

User can pass the required fields and this would be passed to all Operator components which will get added in all deployments created by Operator.

Example:

config:
  nodeSelector:
    key: value
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoSchedule"
  priorityClassName: system-node-critical

This is an Optional section.

NOTE: If spec.config.priorityClassName is used, then the required priorityClass is expected to be created by the user to get the Tekton resources pods in running state

Pipeline

Pipeline section allows user to customize the Tekton pipeline features. This allow user to customize the values in configmaps.

Refer to properties section in TektonPipeline for available options.

Example:

pipeline:
  disable-affinity-assistant: false
  disable-creds-init: false
  disable-home-env-overwrite: true
  disable-working-directory-overwrite: true
  enable-api-fields: stable
  enable-custom-tasks: false
  metrics.pipelinerun.duration-type: histogram
  metrics.pipelinerun.level: pipelinerun
  metrics.taskrun.duration-type: histogram
  metrics.taskrun.level: taskrun
  require-git-ssh-secret-known-hosts: false
  running-in-environment-with-injected-sidecars: true
  trusted-resources-verification-no-match-policy: ignore
  performance:
    replicas: 1
    disable-ha: false
    buckets: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10

Chain

Chain section allows user to customize the Tekton Chain features. This allows user to customize the values in configmaps

Refer to properties section in TektonChain for available options

Example:

chain:
  disabled: false                  # - `disabled` : if the value set as `true`, chains feature will be disabled (default: `false`)
  targetNamespace: tekton-pipelines
  controllerEnvs:
    - name: MONGO_SERVER_URL      # This is the only field supported at the moment which is optional and when added by user, it is added as env to Chains controller
      value: #value               # This can be provided same as env field of container
  artifacts.taskrun.format: in-toto
  artifacts.taskrun.storage: tekton,oci (comma separated values)
  artifacts.taskrun.signer: x509
  artifacts.oci.storage: oci (comma separated values)
  artifacts.oci.format: simplesigning
  artifacts.oci.signer: x509
  artifacts.pipelinerun.format: in-toto
  artifacts.pipelinerun.storage: tekton,oci (comma separated values)
  artifacts.pipelinerun.signer: x509
  storage.gcs.bucket: #value
  storage.oci.repository: #value
  storage.oci.repository.insecure: #value (boolean - true/false)
  storage.docdb.url: #value
  storage.grafeas.projectid: #value
  storage.grafeas.noteid: #value
  storage.grafeas.notehint: #value
  builder.id: #value
  signers.x509.fulcio.enabled: #value (boolean - true/false)
  signers.x509.fulcio.address: #value
  signers.x509.fulcio.issuer: #value
  signers.x509.fulcio.provider: #value
  signers.x509.identity.token.file: #value
  signers.x509.tuf.mirror.url: #value
  signers.kms.kmsref: #value
  signers.kms.kmsref.auth.address: #value
  signers.kms.kmsref.auth.token: #value
  signers.kms.kmsref.auth.oidc.path: #value
  signers.kms.kmsref.auth.oidc.role: #value
  signers.kms.kmsref.auth.spire.sock: #value
  signers.kms.kmsref.auth.spire.audience: #value
  transparency.enabled: #value (boolean - true/false)
  transparency.url: #value

Pruner

Pruner provides auto clean up feature for the Tekton pipelinerun and taskrun resources. In the background pruner container runs tkn command.

Example:

pruner:
  disabled: false
  schedule: "0 8 * * *"
  startingDeadlineSeconds: 100 # optional
  resources:
    - taskrun
    - pipelinerun
  keep: 3
  # keep-since: 1440
  # NOTE: you can use either "keep" or "keep-since", not both
  prune-per-resource: true

disabled : if the value set as true, pruner feature will be disabled (default: false)
schedule: how often to run the pruner job. User can understand the schedule syntax here.
startingDeadlineSeconds: Optional deadline in seconds for starting the job if it misses scheduled time for any reason. Missed jobs executions will be counted as failed ones
resources: supported resources for auto prune are taskrun and pipelinerun
keep: maximum number of resources to keep while deleting or removing resources
keep-since: retain the resources younger than the specified value in minutes
prune-per-resource: if the value set as true (default value false), the keep applied to each resource. The resources(pipeline and/or task) taken dynamically from that namespace and applied.
example: in a namespace ns-1 I have two pipeline, named pipeline-1 and pipeline-2, the out come would be: tkn pipelinerun delete --pipeline=my-pipeline-1 --keep=3 --namespace=ns-1, tkn pipelinerun delete --pipeline=my-pipeline-2 --keep=3 --namespace=ns-1. the same way works for task too.
We do not see any benefit by enabling prune-per-resource=true, when you use keep-since. As keep-since is limiting the resources by time(irrespective of resource count), there is no change on the outcome.

Note:

if disabled: false and schedule: with empty value, global pruner job will be disabled. however, if there is a prune schedule (operator.tekton.dev/prune.schedule) annotation present with a value in a namespace. a namespace wide pruner jobs will be created.

Pruner Namespace annotations

operator.tekton.dev/prune.skip - pruner job will be skipped to a namespace, if the value set as true
operator.tekton.dev/prune.schedule - pruner job will be created on a specific schedule
operator.tekton.dev/prune.keep - maximum number of resources will be kept
operator.tekton.dev/prune.keep-since - retain the resources younger than the specified value in minutes
operator.tekton.dev/prune.prune-per-resource - the keep or keep-since applied to each resource
operator.tekton.dev/prune.resources - can be taskrun and/or pipelinerun, both value can be specified with comma separated. example: taskrun,pipelinerun
operator.tekton.dev/prune.strategy - allowed values: either keep or keep-since

Note:

if a global value is not present the following values will be consider as default value
resources: pipelinerun
keep: 100

Addon

TektonAddon install some resources along with Tekton Pipelines on the cluster. This provides few ClusterTasks, PipelineTemplates, Tasks.

This section allows to customize installation of those resources through params. You can read more about the supported params here.

Example:

addon:
  params:
    - name: "clusterTask"
      value: "true"
    - name: "pipelineTemplates"
      value: "true"
    - name: "resolverTasks"
      value: "true"
    - name: "resolverStepActions"
      value: "true"

NOTE: TektonAddon is currently available for OpenShift Platform only. Enabling this for Kubernetes platform is in roadmap of Operator.

Hub

Example:

hub:
  params:
    - name: enable-devconsole-integration
      value: "false"

Dashboard

Dashboard provides configuration options for the Tekton Dashboard if the specified profile value includes the Dashboard component. (E.g. all on Kubernetes)

Example:

dashboard:
  readonly: true

readonly: If set to true, install the Dashboard in read-only mode

This is an Optional section.

Resolvers

As part of TektonPipelines, resolvers are installed which are by default enabled. User can disable them through TektonConfig.

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    enable-bundles-resolver: true
    enable-cluster-resolver: true
    enable-git-resolver: true
    enable-hub-resolver: true

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    bundles-resolver-config:
      default-service-account: pipelines
    cluster-resolver-config:
      default-namespace: cluster-resolver-test
    enable-bundles-resolver: true
    enable-cluster-resolver: true
    enable-git-resolver: true
    enable-hub-resolver: true
    git-resolver-config:
      server-url: localhost.com
    hub-resolver-config:
      default-tekton-hub-catalog: tekton
      tekton-hub-api: "https://my-custom-tekton-hub.example.com"
      artifact-hub-api: "https://my-custom-artifact-hub.example.com"

tekton-hub-api => TEKTON_HUB_API
artifact-hub-api => ARTIFACT_HUB_API

OpenShiftPipelinesAsCode

Example:

platforms:
  openshift:
    pipelinesAsCode:
      additionalPACControllers:
        controllername:
          enable: true
          configMapName:
          secretName:
          settings:
      enable: true
      settings:
        application-name: Pipelines as Code CI
        auto-configure-new-github-repo: "false"
        bitbucket-cloud-check-source-ip: "true"
        custom-console-name: ""
        custom-console-url: ""
        custom-console-url-pr-details: ""
        custom-console-url-pr-tasklog: ""
        error-detection-from-container-logs: "false"
        error-detection-max-number-of-lines: "50"
        error-detection-simple-regexp: ^(?P<filename>[^:]*):(?P<line>[0-9]+):(?P<column>[0-9]+):([
          ]*)?(?P<error>.*)
        error-log-snippet: "true"
        hub-catalog-name: tekton
        hub-url: https://api.hub.tekton.dev/v1
        remote-tasks: "true"
        secret-auto-create: "true"
        secret-github-app-token-scoped: "true"

NOTE: OpenShiftPipelinesAsCode is currently available for the OpenShift Platform only.

Additional fields as `options`

There is a field called options available in all the components.

NOTE: There is a possibility to have two different values for a field.
An example: with a pre-defined field you can set value and the same field may be defined under options as well. In that case value from options will be final.

A sample options field,

options:
  disabled: false
  configMaps:
    config-leader-election: # name of the configMap
      data:
        lease-duration: "90s"
    pipeline-config-logging: # creates new configMap under targetNamespace
      metadata:
        labels:
          my-custom-logger: "true"
        annotations:
          logger-type: "uber-zap"
      data:
        loglevel.controller: "info"
        loglevel.webhook: "info"
        zap-logger-config: |
          {
            "level": "debug",
            "development": false,
            "sampling": {
              "initial": 100,
              "thereafter": 50
            },
            "outputPaths": ["stdout"],
            "errorOutputPaths": ["stderr"],
            "encoding": "json",
            "encoderConfig": {
              "timeKey": "ts",
              "levelKey": "severity",
              "nameKey": "logger",
              "callerKey": "caller",
              "messageKey": "message",
              "stacktraceKey": "stacktrace",
              "lineEnding": "",
              "levelEncoder": "",
              "timeEncoder": "iso8601",
              "durationEncoder": "",
              "callerEncoder": ""
            }
          }          

  deployments:
    tekton-pipelines-controller: # name of the deployment
      metadata:
        labels:
          custom-label: "foo"
        annotations:
          custom-annotation: "foo"
      spec:
        replicas: 2
        template:
          spec:
            containers:
              - name: tekton-pipelines-controller
                env:
                  - name: CONFIG_LOGGING_NAME
                    value: pipeline-config-logging
  statefulSets:
    web: # name of the statefulSets
      metadata:
        labels:
          custom-label: foo
        annotations:
          custom-annotation: foo
      spec:
        replicas: 3
        template:
          spec:
            containers:
              - name: nginx
                env:
                  - name: NGINX_MODE
                    value: production
  horizontalPodAutoscalers:
    tekton-pipelines-webhook: # name of the hpa
      metadata:
        annotations:
        labels:
      spec:
        minReplicas: 2
        maxReplicas: 7
        metrics:
        - resource:
            name: cpu
            target:
              averageUtilization: 85
              type: Utilization
          type: Resource
  webhookConfigurationOptions:
    validation.webhook.pipeline.tekton.dev:
      failurePolicy: Fail
      timeoutSeconds: 20
      sideEffects: None
    webhook.pipeline.tekton.dev:
      failurePolicy: Fail
      timeoutSeconds: 20
      sideEffects: None

disabled - disables the additional options support, if disabled set to true. default: false

ConfigMaps

Supports to update existing configMap also supports to create new configMap.

The following fields are supported in configMap

metadata
- labels - supports add and update
- annotations - supports add and update
data - supports add and update

Deployments

Supports to update the existing deployments. But not supported to create new deployment.

The following fields are supported in deployment

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- replicas - updates deployment replicas count
- template
  - metadata
    - labels - supports add and update
    - annotations - supports add and update
  - spec
    - affinity - replaces the existing Affinity with this, if not empty
    - priorityClassName - replaces the existing PriorityClassName with this, if not empty
    - nodeSelector - replaces the existing NodeSelector with this, if not empty
    - tolerations - replaces the existing tolerations with this, if not empty
    - topologySpreadConstraints - replaces the existing TopologySpreadConstraints with this, if not empty
    - volumes - adds and updates volumes
    - initContainers - updates init-containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS
    - containers - updates containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS

StatefulSets

Supports to update the existing StatefulSet. But not supported to create new StatefulSet.

The following fields are supported in StatefulSet

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- replicas - updates statefulSets replicas count
- serviceName - updates service name
- podManagementPolicy - updates pod management policy
- volumeClaimTemplates - updates volume claim templates
- template
  - metadata
    - labels - supports add and update
    - annotations - supports add and update
  - spec
    - affinity - replaces the existing Affinity with this, if not empty
    - priorityClassName - replaces the existing PriorityClassName with this, if not empty
    - nodeSelector - replaces the existing NodeSelector with this, if not empty
    - tolerations - replaces the existing tolerations with this, if not empty
    - topologySpreadConstraints - replaces the existing TopologySpreadConstraints with this, if not empty
    - volumes - adds and updates volumes
    - initContainers - updates init-containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS
    - containers - updates containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS

HorizontalPodAutoscalers

Supports to update the existing HorizontalPodAutoscaler(HPA) also supports to create new HPA.

The following fields are supported in HorizontalPodAutoscaler (aka HPA)

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- scaleTargetRef - replaces scaleTargetRef with this, if kind and name are not empty
- minReplicas - updates minimum replicas count
- maxReplicas - updates maximum replicas count
- metrics - replaces the metrics details with this array, if not empty
- behavior - updates behavior data with this, if not empty
  - scaleUp - replaces scaleUp with this, if not empty
  - scaleDown - replaces scaleDown with this, if not empty

webhookConfigurationOptions

the following options are supported for webhookConfigurationOptions

failurePolicy - defines how unrecognized errors and timeout errors from the admission webhook are handled. Allowed values are Ignore or Fail
timeoutSeconds - allows configuring how long the API server should wait for a webhook to respond before treating the call as a failure.
sideEffects - indicates whether the webhook have a side effet. Allowed values are None, NoneOnDryRun, Unknown, or Some

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Config

TektonConfig custom resource is the top most component of the operator which allows user to install and customize all other components at a single place.

Operator provides support for installing and managing following operator components through TektonConfig:

Other than the above components depending on the platform operator also provides support for

On both Kubernetes and OpenShift
- TektonChain
On Kubernetes
- TektonDashboard
On OpenShift
- TektonAddon
- OpenShiftPipelinesAsCode

The TektonConfig CR provides the following features

  apiVersion: operator.tekton.dev/v1alpha1
  kind: TektonConfig
  metadata:
    name: config
  spec:
    targetNamespace: tekton-pipelines
    targetNamespaceMetadata:
      labels: {}
      annotations: {}
    profile: all
    config:
      nodeSelector: <>
      tolerations: []
      priorityClassName: system-cluster-critical
    chain:
      disabled: false
    pipeline:
      await-sidecar-readiness: true
      coschedule: workspaces
      disable-affinity-assistant: false
      disable-creds-init: false
      disable-home-env-overwrite: true
      disable-working-directory-overwrite: true
      disable-inline-spec: "pipeline,pipelinerun,taskrun"
      enable-api-fields: beta
      enable-bundles-resolver: true
      enable-cel-in-whenexpression: false
      enable-cluster-resolver: true
      enable-custom-tasks: true
      enable-git-resolver: true
      enable-hub-resolver: true
      enable-param-enum: false
      enable-provenance-in-status: true
      enable-step-actions: false
      enforce-nonfalsifiability: none
      keep-pod-on-cancel: false
      max-result-size: 4096
      metrics.count.enable-reason: false
      metrics.pipelinerun.duration-type: histogram
      metrics.pipelinerun.level: pipeline
      metrics.taskrun.duration-type: histogram
      metrics.taskrun.level: task
      require-git-ssh-secret-known-hosts: false
      results-from: termination-message
      running-in-environment-with-injected-sidecars: true
      send-cloudevents-for-runs: false
      set-security-context: false
      trusted-resources-verification-no-match-policy: ignore
      performance:
        disable-ha: false
        buckets: 1
        replicas: 1
        threads-per-controller: 2
        kube-api-qps: 5.0
        kube-api-burst: 10
      options:
        disabled: false
        configMaps: {}
        deployments: {}
        webhookConfigurationOptions: {}
    pruner:
      disabled: false
      schedule: "0 8 * * *"
      resources:
        - taskrun
        - pipelinerun
      keep: 3
      # keep-since: 1440
      # NOTE: you can use either "keep" or "keep-since", not both
      prune-per-resource: true
    hub:
      params:
        - name: enable-devconsole-integration
          value: "true"
      options:
        disabled: false
        configMaps: {}
        deployments: {}
        webhookConfigurationOptions: {}
    dashboard:
      readonly: true
      options:
        disabled: false
        configMaps: {}
        deployments: {}
        webhookConfigurationOptions: {}
    platforms:
      openshift:
        pipelinesAsCode:
          additionalPACControllers:
            <controllerName>:
              enable: true
              configMapName:
              secretName:
              settings:
          enable: true
          settings:
            application-name: Pipelines as Code CI
            auto-configure-new-github-repo: "false"
            bitbucket-cloud-check-source-ip: "true"
            custom-console-name: ""
            custom-console-url: ""
            custom-console-url-pr-details: ""
            custom-console-url-pr-tasklog: ""
            error-detection-from-container-logs: "false"
            error-detection-max-number-of-lines: "50"
            error-detection-simple-regexp: ^(?P<filename>[^:]*):(?P<line>[0-9]+):(?P<column>[0-9]+):([
              ]*)?(?P<error>.*)
            error-log-snippet: "true"
            hub-catalog-name: tekton
            hub-url: https://api.hub.tekton.dev/v1
            remote-tasks: "true"
            secret-auto-create: "true"
            secret-github-app-token-scoped: "true"
        options:
          disabled: false
          configMaps: {}
          deployments: {}
          webhookConfigurationOptions: {}

Look for the particular section to understand a particular field in the spec.

Target Namespace

This allows user to choose a namespace to install the Tekton Components such as pipelines, triggers.

By default, namespace would be tekton-pipelines for Kubernetes and openshift-pipelines for OpenShift.

Note: Namespace openshift-operators is not allowed in OpenShift as a targetNamespace.

Target Namespace Metadata

targetNamespaceMetadata allows user to add their custom labels and annotations to the target namespace via TektonConfig CR.

Profile

This allows user to choose which all components to install on the cluster. There are 3 profiles available:

all: This profile will install all components (TektonPipeline, TektonTrigger and TektonChain)
basic: This profile will install only TektonPipeline, TektonTrigger and TektonChain component
lite: This profile will install only TektonPipeline component

On Kubernetes, all profile will install TektonDashboard and on OpenShift TektonAddon will be installed.

Config

Config provides fields to configure deployments created by the Operator. This provides following fields:

User can pass the required fields and this would be passed to all Operator components which will get added in all deployments created by Operator.

Example:

config:
  nodeSelector:
    key: value
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoSchedule"
  priorityClassName: system-node-critical

This is an Optional section.

NOTE: If spec.config.priorityClassName is used, then the required priorityClass is expected to be created by the user to get the Tekton resources pods in running state

Pipeline

Pipeline section allows user to customize the Tekton pipeline features. This allow user to customize the values in configmaps.

Refer to properties section in TektonPipeline for available options.

Example:

pipeline:
  disable-affinity-assistant: false
  disable-creds-init: false
  disable-home-env-overwrite: true
  disable-working-directory-overwrite: true
  enable-api-fields: stable
  enable-custom-tasks: false
  metrics.pipelinerun.duration-type: histogram
  metrics.pipelinerun.level: pipelinerun
  metrics.taskrun.duration-type: histogram
  metrics.taskrun.level: taskrun
  require-git-ssh-secret-known-hosts: false
  running-in-environment-with-injected-sidecars: true
  trusted-resources-verification-no-match-policy: ignore
  performance:
    replicas: 1
    disable-ha: false
    buckets: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10

Chain

Chain section allows user to customize the Tekton Chain features. This allows user to customize the values in configmaps

Refer to properties section in TektonChain for available options

Example:

chain:
  disabled: false                  # - `disabled` : if the value set as `true`, chains feature will be disabled (default: `false`)
  targetNamespace: tekton-pipelines
  generateSigningSecret: true # default value: false
  controllerEnvs:
    - name: MONGO_SERVER_URL      # This is the only field supported at the moment which is optional and when added by user, it is added as env to Chains controller
      value: #value               # This can be provided same as env field of container
  artifacts.taskrun.format: in-toto
  artifacts.taskrun.storage: tekton,oci (comma separated values)
  artifacts.taskrun.signer: x509
  artifacts.oci.storage: oci (comma separated values)
  artifacts.oci.format: simplesigning
  artifacts.oci.signer: x509
  artifacts.pipelinerun.format: in-toto
  artifacts.pipelinerun.storage: tekton,oci (comma separated values)
  artifacts.pipelinerun.signer: x509
  storage.gcs.bucket: #value
  storage.oci.repository: #value
  storage.oci.repository.insecure: #value (boolean - true/false)
  storage.docdb.url: #value
  storage.grafeas.projectid: #value
  storage.grafeas.noteid: #value
  storage.grafeas.notehint: #value
  builder.id: #value
  signers.x509.fulcio.enabled: #value (boolean - true/false)
  signers.x509.fulcio.address: #value
  signers.x509.fulcio.issuer: #value
  signers.x509.fulcio.provider: #value
  signers.x509.identity.token.file: #value
  signers.x509.tuf.mirror.url: #value
  signers.kms.kmsref: #value
  signers.kms.kmsref.auth.address: #value
  signers.kms.kmsref.auth.token: #value
  signers.kms.kmsref.auth.oidc.path: #value
  signers.kms.kmsref.auth.oidc.role: #value
  signers.kms.kmsref.auth.spire.sock: #value
  signers.kms.kmsref.auth.spire.audience: #value
  transparency.enabled: #value (boolean - true/false)
  transparency.url: #value

Pruner

Pruner provides auto clean up feature for the Tekton pipelinerun and taskrun resources. In the background pruner container runs tkn command.

Example:

pruner:
  disabled: false
  schedule: "0 8 * * *"
  startingDeadlineSeconds: 100 # optional
  resources:
    - taskrun
    - pipelinerun
  keep: 3
  # keep-since: 1440
  # NOTE: you can use either "keep" or "keep-since", not both
  prune-per-resource: true

disabled : if the value set as true, pruner feature will be disabled (default: false)
schedule: how often to run the pruner job. User can understand the schedule syntax here.
startingDeadlineSeconds: Optional deadline in seconds for starting the job if it misses scheduled time for any reason. Missed jobs executions will be counted as failed ones
resources: supported resources for auto prune are taskrun and pipelinerun
keep: maximum number of resources to keep while deleting or removing resources
keep-since: retain the resources younger than the specified value in minutes
prune-per-resource: if the value set as true (default value false), the keep applied to each resource. The resources(pipeline and/or task) taken dynamically from that namespace and applied.
example: in a namespace ns-1 I have two pipeline, named pipeline-1 and pipeline-2, the out come would be: tkn pipelinerun delete --pipeline=my-pipeline-1 --keep=3 --namespace=ns-1, tkn pipelinerun delete --pipeline=my-pipeline-2 --keep=3 --namespace=ns-1. the same way works for task too.
We do not see any benefit by enabling prune-per-resource=true, when you use keep-since. As keep-since is limiting the resources by time(irrespective of resource count), there is no change on the outcome.

Note:

if disabled: false and schedule: with empty value, global pruner job will be disabled. however, if there is a prune schedule (operator.tekton.dev/prune.schedule) annotation present with a value in a namespace. a namespace wide pruner jobs will be created.

Pruner Namespace annotations

operator.tekton.dev/prune.skip - pruner job will be skipped to a namespace, if the value set as true
operator.tekton.dev/prune.schedule - pruner job will be created on a specific schedule
operator.tekton.dev/prune.keep - maximum number of resources will be kept
operator.tekton.dev/prune.keep-since - retain the resources younger than the specified value in minutes
operator.tekton.dev/prune.prune-per-resource - the keep or keep-since applied to each resource
operator.tekton.dev/prune.resources - can be taskrun and/or pipelinerun, both value can be specified with comma separated. example: taskrun,pipelinerun
operator.tekton.dev/prune.strategy - allowed values: either keep or keep-since

Note:

if a global value is not present the following values will be consider as default value
resources: pipelinerun
keep: 100

Addon

TektonAddon install some resources along with Tekton Pipelines on the cluster. This provides few PipelineTemplates, ResolverTasks and ResolverStepActions.

This section allows to customize installation of those resources through params. You can read more about the supported params here.

Example:

addon:
  params:
    - name: "pipelineTemplates"
      value: "true"
    - name: "resolverTasks"
      value: "true"
    - name: "resolverStepActions"
      value: "true"

NOTE: TektonAddon is currently available for OpenShift Platform only. Enabling this for Kubernetes platform is in roadmap of Operator.

Hub

Example:

hub:
  params:
    - name: enable-devconsole-integration
      value: "false"

Dashboard

Dashboard provides configuration options for the Tekton Dashboard if the specified profile value includes the Dashboard component. (E.g. all on Kubernetes)

Example:

dashboard:
  readonly: true

readonly: If set to true, install the Dashboard in read-only mode

This is an Optional section.

Resolvers

As part of TektonPipelines, resolvers are installed which are by default enabled. User can disable them through TektonConfig.

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    enable-bundles-resolver: true
    enable-cluster-resolver: true
    enable-git-resolver: true
    enable-hub-resolver: true

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    bundles-resolver-config:
      default-service-account: pipelines
    cluster-resolver-config:
      default-namespace: cluster-resolver-test
    enable-bundles-resolver: true
    enable-cluster-resolver: true
    enable-git-resolver: true
    enable-hub-resolver: true
    git-resolver-config:
      server-url: localhost.com
    hub-resolver-config:
      default-tekton-hub-catalog: tekton
      tekton-hub-api: "https://my-custom-tekton-hub.example.com"
      artifact-hub-api: "https://my-custom-artifact-hub.example.com"

tekton-hub-api => TEKTON_HUB_API
artifact-hub-api => ARTIFACT_HUB_API

OpenShiftPipelinesAsCode

Example:

platforms:
  openshift:
    pipelinesAsCode:
      additionalPACControllers:
        controllername:
          enable: true
          configMapName:
          secretName:
          settings:
      enable: true
      settings:
        application-name: Pipelines as Code CI
        auto-configure-new-github-repo: "false"
        bitbucket-cloud-check-source-ip: "true"
        custom-console-name: ""
        custom-console-url: ""
        custom-console-url-pr-details: ""
        custom-console-url-pr-tasklog: ""
        error-detection-from-container-logs: "false"
        error-detection-max-number-of-lines: "50"
        error-detection-simple-regexp: ^(?P<filename>[^:]*):(?P<line>[0-9]+):(?P<column>[0-9]+):([
          ]*)?(?P<error>.*)
        error-log-snippet: "true"
        hub-catalog-name: tekton
        hub-url: https://api.hub.tekton.dev/v1
        remote-tasks: "true"
        secret-auto-create: "true"
        secret-github-app-token-scoped: "true"

NOTE: OpenShiftPipelinesAsCode is currently available for the OpenShift Platform only.

Additional fields as `options`

There is a field called options available in all the components.

NOTE: There is a possibility to have two different values for a field.
An example: with a pre-defined field you can set value and the same field may be defined under options as well. In that case value from options will be final.

A sample options field,

options:
  disabled: false
  configMaps:
    config-leader-election: # name of the configMap
      data:
        lease-duration: "90s"
    pipeline-config-logging: # creates new configMap under targetNamespace
      metadata:
        labels:
          my-custom-logger: "true"
        annotations:
          logger-type: "uber-zap"
      data:
        loglevel.controller: "info"
        loglevel.webhook: "info"
        zap-logger-config: |
          {
            "level": "debug",
            "development": false,
            "sampling": {
              "initial": 100,
              "thereafter": 50
            },
            "outputPaths": ["stdout"],
            "errorOutputPaths": ["stderr"],
            "encoding": "json",
            "encoderConfig": {
              "timeKey": "ts",
              "levelKey": "severity",
              "nameKey": "logger",
              "callerKey": "caller",
              "messageKey": "message",
              "stacktraceKey": "stacktrace",
              "lineEnding": "",
              "levelEncoder": "",
              "timeEncoder": "iso8601",
              "durationEncoder": "",
              "callerEncoder": ""
            }
          }          

  deployments:
    tekton-pipelines-controller: # name of the deployment
      metadata:
        labels:
          custom-label: "foo"
        annotations:
          custom-annotation: "foo"
      spec:
        replicas: 2
        template:
          spec:
            containers:
              - name: tekton-pipelines-controller
                env:
                  - name: CONFIG_LOGGING_NAME
                    value: pipeline-config-logging
  statefulSets:
    web: # name of the statefulSets
      metadata:
        labels:
          custom-label: foo
        annotations:
          custom-annotation: foo
      spec:
        replicas: 3
        template:
          spec:
            containers:
              - name: nginx
                env:
                  - name: NGINX_MODE
                    value: production
  horizontalPodAutoscalers:
    tekton-pipelines-webhook: # name of the hpa
      metadata:
        annotations:
        labels:
      spec:
        minReplicas: 2
        maxReplicas: 7
        metrics:
        - resource:
            name: cpu
            target:
              averageUtilization: 85
              type: Utilization
          type: Resource
  webhookConfigurationOptions:
    validation.webhook.pipeline.tekton.dev:
      failurePolicy: Fail
      timeoutSeconds: 20
      sideEffects: None
    webhook.pipeline.tekton.dev:
      failurePolicy: Fail
      timeoutSeconds: 20
      sideEffects: None

disabled - disables the additional options support, if disabled set to true. default: false

ConfigMaps

Supports to update existing configMap also supports to create new configMap.

The following fields are supported in configMap

metadata
- labels - supports add and update
- annotations - supports add and update
data - supports add and update

Deployments

Supports to update the existing deployments. But not supported to create new deployment.

The following fields are supported in deployment

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- replicas - updates deployment replicas count
- template
  - metadata
    - labels - supports add and update
    - annotations - supports add and update
  - spec
    - affinity - replaces the existing Affinity with this, if not empty
    - priorityClassName - replaces the existing PriorityClassName with this, if not empty
    - nodeSelector - replaces the existing NodeSelector with this, if not empty
    - tolerations - replaces the existing tolerations with this, if not empty
    - topologySpreadConstraints - replaces the existing TopologySpreadConstraints with this, if not empty
    - volumes - adds and updates volumes
    - initContainers - updates init-containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS
    - containers - updates containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS

StatefulSets

Supports to update the existing StatefulSet. But not supported to create new StatefulSet.

The following fields are supported in StatefulSet

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- replicas - updates statefulSets replicas count
- serviceName - updates service name
- podManagementPolicy - updates pod management policy
- volumeClaimTemplates - updates volume claim templates
- template
  - metadata
    - labels - supports add and update
    - annotations - supports add and update
  - spec
    - affinity - replaces the existing Affinity with this, if not empty
    - priorityClassName - replaces the existing PriorityClassName with this, if not empty
    - nodeSelector - replaces the existing NodeSelector with this, if not empty
    - tolerations - replaces the existing tolerations with this, if not empty
    - topologySpreadConstraints - replaces the existing TopologySpreadConstraints with this, if not empty
    - volumes - adds and updates volumes
    - initContainers - updates init-containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS
    - containers - updates containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS

HorizontalPodAutoscalers

Supports to update the existing HorizontalPodAutoscaler(HPA) also supports to create new HPA.

The following fields are supported in HorizontalPodAutoscaler (aka HPA)

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- scaleTargetRef - replaces scaleTargetRef with this, if kind and name are not empty
- minReplicas - updates minimum replicas count
- maxReplicas - updates maximum replicas count
- metrics - replaces the metrics details with this array, if not empty
- behavior - updates behavior data with this, if not empty
  - scaleUp - replaces scaleUp with this, if not empty
  - scaleDown - replaces scaleDown with this, if not empty

webhookConfigurationOptions

the following options are supported for webhookConfigurationOptions

failurePolicy - defines how unrecognized errors and timeout errors from the admission webhook are handled. Allowed values are Ignore or Fail
timeoutSeconds - allows configuring how long the API server should wait for a webhook to respond before treating the call as a failure.
sideEffects - indicates whether the webhook have a side effet. Allowed values are None, NoneOnDryRun, Unknown, or Some

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Config

TektonConfig custom resource is the top most component of the operator which allows user to install and customize all other components at a single place.

Operator provides support for installing and managing following operator components through TektonConfig:

Other than the above components depending on the platform operator also provides support for

On both Kubernetes and OpenShift
- TektonChain
On Kubernetes
- TektonDashboard
On OpenShift
- TektonAddon
- OpenShiftPipelinesAsCode

The TektonConfig CR provides the following features

  apiVersion: operator.tekton.dev/v1alpha1
  kind: TektonConfig
  metadata:
    name: config
  spec:
    targetNamespace: tekton-pipelines
    targetNamespaceMetadata:
      labels: {}
      annotations: {}
    profile: all
    config:
      nodeSelector: <>
      tolerations: []
      priorityClassName: system-cluster-critical
    chain:
      disabled: false
    pipeline:
      await-sidecar-readiness: true
      coschedule: workspaces
      disable-affinity-assistant: false
      disable-creds-init: false
      disable-home-env-overwrite: true
      disable-working-directory-overwrite: true
      disable-inline-spec: "pipeline,pipelinerun,taskrun"
      enable-api-fields: beta
      enable-bundles-resolver: true
      enable-cel-in-whenexpression: false
      enable-cluster-resolver: true
      enable-custom-tasks: true
      enable-git-resolver: true
      enable-hub-resolver: true
      enable-param-enum: false
      enable-provenance-in-status: true
      enable-step-actions: false
      enforce-nonfalsifiability: none
      keep-pod-on-cancel: false
      max-result-size: 4096
      metrics.count.enable-reason: false
      metrics.pipelinerun.duration-type: histogram
      metrics.pipelinerun.level: pipeline
      metrics.taskrun.duration-type: histogram
      metrics.taskrun.level: task
      require-git-ssh-secret-known-hosts: false
      results-from: termination-message
      running-in-environment-with-injected-sidecars: true
      send-cloudevents-for-runs: false
      set-security-context: false
      trusted-resources-verification-no-match-policy: ignore
      performance:
        disable-ha: false
        buckets: 1
        replicas: 1
        threads-per-controller: 2
        kube-api-qps: 5.0
        kube-api-burst: 10
      options:
        disabled: false
        configMaps: {}
        deployments: {}
        webhookConfigurationOptions: {}
    pruner:
      disabled: false
      schedule: "0 8 * * *"
      resources:
        - taskrun
        - pipelinerun
      keep: 3
      # keep-since: 1440
      # NOTE: you can use either "keep" or "keep-since", not both
      prune-per-resource: true
    hub:
      params:
        - name: enable-devconsole-integration
          value: "true"
      options:
        disabled: false
        configMaps: {}
        deployments: {}
        webhookConfigurationOptions: {}
    dashboard:
      readonly: true
      options:
        disabled: false
        configMaps: {}
        deployments: {}
        webhookConfigurationOptions: {}
    platforms:
      openshift:
        pipelinesAsCode:
          additionalPACControllers:
            <controllerName>:
              enable: true
              configMapName:
              secretName:
              settings:
          enable: true
          settings:
            application-name: Pipelines as Code CI
            auto-configure-new-github-repo: "false"
            bitbucket-cloud-check-source-ip: "true"
            custom-console-name: ""
            custom-console-url: ""
            custom-console-url-pr-details: ""
            custom-console-url-pr-tasklog: ""
            error-detection-from-container-logs: "false"
            error-detection-max-number-of-lines: "50"
            error-detection-simple-regexp: ^(?P<filename>[^:]*):(?P<line>[0-9]+):(?P<column>[0-9]+):([
              ]*)?(?P<error>.*)
            error-log-snippet: "true"
            hub-catalog-name: tekton
            hub-url: https://api.hub.tekton.dev/v1
            remote-tasks: "true"
            secret-auto-create: "true"
            secret-github-app-token-scoped: "true"
        options:
          disabled: false
          configMaps: {}
          deployments: {}
          webhookConfigurationOptions: {}

Look for the particular section to understand a particular field in the spec.

Target Namespace

This allows user to choose a namespace to install the Tekton Components such as pipelines, triggers.

By default, namespace would be tekton-pipelines for Kubernetes and openshift-pipelines for OpenShift.

Note: Namespace openshift-operators is not allowed in OpenShift as a targetNamespace.

Target Namespace Metadata

targetNamespaceMetadata allows user to add their custom labels and annotations to the target namespace via TektonConfig CR.

Profile

This allows user to choose which all components to install on the cluster. There are 3 profiles available:

all: This profile will install all components (TektonPipeline, TektonTrigger and TektonChain)
basic: This profile will install only TektonPipeline, TektonTrigger and TektonChain component
lite: This profile will install only TektonPipeline component

On Kubernetes, all profile will install TektonDashboard and on OpenShift TektonAddon will be installed.

Config

Config provides fields to configure deployments created by the Operator. This provides following fields:

User can pass the required fields and this would be passed to all Operator components which will get added in all deployments created by Operator.

Example:

config:
  nodeSelector:
    key: value
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoSchedule"
  priorityClassName: system-node-critical

This is an Optional section.

NOTE: If spec.config.priorityClassName is used, then the required priorityClass is expected to be created by the user to get the Tekton resources pods in running state

Pipeline

Pipeline section allows user to customize the Tekton pipeline features. This allow user to customize the values in configmaps.

Refer to properties section in TektonPipeline for available options.

Example:

pipeline:
  disable-affinity-assistant: false
  disable-creds-init: false
  disable-home-env-overwrite: true
  disable-working-directory-overwrite: true
  enable-api-fields: stable
  enable-custom-tasks: false
  metrics.pipelinerun.duration-type: histogram
  metrics.pipelinerun.level: pipelinerun
  metrics.taskrun.duration-type: histogram
  metrics.taskrun.level: taskrun
  require-git-ssh-secret-known-hosts: false
  running-in-environment-with-injected-sidecars: true
  trusted-resources-verification-no-match-policy: ignore
  performance:
    replicas: 1
    disable-ha: false
    buckets: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10

Chain

Chain section allows user to customize the Tekton Chain features. This allows user to customize the values in configmaps

Refer to properties section in TektonChain for available options

Example:

chain:
  disabled: false                  # - `disabled` : if the value set as `true`, chains feature will be disabled (default: `false`)
  targetNamespace: tekton-pipelines
  generateSigningSecret: true # default value: false
  controllerEnvs:
    - name: MONGO_SERVER_URL      # This is the only field supported at the moment which is optional and when added by user, it is added as env to Chains controller
      value: #value               # This can be provided same as env field of container
  artifacts.taskrun.format: in-toto
  artifacts.taskrun.storage: tekton,oci (comma separated values)
  artifacts.taskrun.signer: x509
  artifacts.oci.storage: oci (comma separated values)
  artifacts.oci.format: simplesigning
  artifacts.oci.signer: x509
  artifacts.pipelinerun.format: in-toto
  artifacts.pipelinerun.storage: tekton,oci (comma separated values)
  artifacts.pipelinerun.signer: x509
  storage.gcs.bucket: #value
  storage.oci.repository: #value
  storage.oci.repository.insecure: #value (boolean - true/false)
  storage.docdb.url: #value
  storage.grafeas.projectid: #value
  storage.grafeas.noteid: #value
  storage.grafeas.notehint: #value
  builder.id: #value
  signers.x509.fulcio.enabled: #value (boolean - true/false)
  signers.x509.fulcio.address: #value
  signers.x509.fulcio.issuer: #value
  signers.x509.fulcio.provider: #value
  signers.x509.identity.token.file: #value
  signers.x509.tuf.mirror.url: #value
  signers.kms.kmsref: #value
  signers.kms.kmsref.auth.address: #value
  signers.kms.kmsref.auth.token: #value
  signers.kms.kmsref.auth.oidc.path: #value
  signers.kms.kmsref.auth.oidc.role: #value
  signers.kms.kmsref.auth.spire.sock: #value
  signers.kms.kmsref.auth.spire.audience: #value
  transparency.enabled: #value (boolean - true/false)
  transparency.url: #value

Pruner

Pruner provides auto clean up feature for the Tekton pipelinerun and taskrun resources. In the background pruner container runs tkn command.

Example:

pruner:
  disabled: false
  schedule: "0 8 * * *"
  startingDeadlineSeconds: 100 # optional
  resources:
    - taskrun
    - pipelinerun
  keep: 3
  # keep-since: 1440
  # NOTE: you can use either "keep" or "keep-since", not both
  prune-per-resource: true

disabled : if the value set as true, pruner feature will be disabled (default: false)
schedule: how often to run the pruner job. User can understand the schedule syntax here.
startingDeadlineSeconds: Optional deadline in seconds for starting the job if it misses scheduled time for any reason. Missed jobs executions will be counted as failed ones
resources: supported resources for auto prune are taskrun and pipelinerun
keep: maximum number of resources to keep while deleting or removing resources
keep-since: retain the resources younger than the specified value in minutes
prune-per-resource: if the value set as true (default value false), the keep applied to each resource. The resources(pipeline and/or task) taken dynamically from that namespace and applied.
example: in a namespace ns-1 I have two pipeline, named pipeline-1 and pipeline-2, the out come would be: tkn pipelinerun delete --pipeline=my-pipeline-1 --keep=3 --namespace=ns-1, tkn pipelinerun delete --pipeline=my-pipeline-2 --keep=3 --namespace=ns-1. the same way works for task too.
We do not see any benefit by enabling prune-per-resource=true, when you use keep-since. As keep-since is limiting the resources by time(irrespective of resource count), there is no change on the outcome.

Note:

if disabled: false and schedule: with empty value, global pruner job will be disabled. however, if there is a prune schedule (operator.tekton.dev/prune.schedule) annotation present with a value in a namespace. a namespace wide pruner jobs will be created.

Pruner Namespace annotations

operator.tekton.dev/prune.skip - pruner job will be skipped to a namespace, if the value set as true
operator.tekton.dev/prune.schedule - pruner job will be created on a specific schedule
operator.tekton.dev/prune.keep - maximum number of resources will be kept
operator.tekton.dev/prune.keep-since - retain the resources younger than the specified value in minutes
operator.tekton.dev/prune.prune-per-resource - the keep or keep-since applied to each resource
operator.tekton.dev/prune.resources - can be taskrun and/or pipelinerun, both value can be specified with comma separated. example: taskrun,pipelinerun
operator.tekton.dev/prune.strategy - allowed values: either keep or keep-since

Note:

if a global value is not present the following values will be consider as default value
resources: pipelinerun
keep: 100

Addon

TektonAddon install some resources along with Tekton Pipelines on the cluster. This provides few PipelineTemplates, ResolverTasks, ResolverStepActions and CommunityResolverTasks.

This section allows to customize installation of those resources through params. You can read more about the supported params here.

Example:

addon:
  params:
    - name: "pipelineTemplates"
      value: "true"
    - name: "resolverTasks"
      value: "true"
    - name: "resolverStepActions"
      value: "true"
    - name: "communityResolverTasks"
      value: "true"

NOTE: TektonAddon is currently available for OpenShift Platform only. Enabling this for Kubernetes platform is in roadmap of Operator.

Hub

Example:

hub:
  params:
    - name: enable-devconsole-integration
      value: "false"

Dashboard

Dashboard provides configuration options for the Tekton Dashboard if the specified profile value includes the Dashboard component. (E.g. all on Kubernetes)

Example:

dashboard:
  readonly: true

readonly: If set to true, install the Dashboard in read-only mode

This is an Optional section.

Resolvers

As part of TektonPipelines, resolvers are installed which are by default enabled. User can disable them through TektonConfig.

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    enable-bundles-resolver: true
    enable-cluster-resolver: true
    enable-git-resolver: true
    enable-hub-resolver: true

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    bundles-resolver-config:
      default-service-account: pipelines
    cluster-resolver-config:
      default-namespace: cluster-resolver-test
    enable-bundles-resolver: true
    enable-cluster-resolver: true
    enable-git-resolver: true
    enable-hub-resolver: true
    git-resolver-config:
      server-url: localhost.com
    hub-resolver-config:
      default-tekton-hub-catalog: tekton
      tekton-hub-api: "https://my-custom-tekton-hub.example.com"
      artifact-hub-api: "https://my-custom-artifact-hub.example.com"

tekton-hub-api => TEKTON_HUB_API
artifact-hub-api => ARTIFACT_HUB_API

OpenShiftPipelinesAsCode

Example:

platforms:
  openshift:
    pipelinesAsCode:
      additionalPACControllers:
        controllername:
          enable: true
          configMapName:
          secretName:
          settings:
      enable: true
      settings:
        application-name: Pipelines as Code CI
        auto-configure-new-github-repo: "false"
        bitbucket-cloud-check-source-ip: "true"
        custom-console-name: ""
        custom-console-url: ""
        custom-console-url-pr-details: ""
        custom-console-url-pr-tasklog: ""
        error-detection-from-container-logs: "false"
        error-detection-max-number-of-lines: "50"
        error-detection-simple-regexp: ^(?P<filename>[^:]*):(?P<line>[0-9]+):(?P<column>[0-9]+):([
          ]*)?(?P<error>.*)
        error-log-snippet: "true"
        hub-catalog-name: tekton
        hub-url: https://api.hub.tekton.dev/v1
        remote-tasks: "true"
        secret-auto-create: "true"
        secret-github-app-token-scoped: "true"

NOTE: OpenShiftPipelinesAsCode is currently available for the OpenShift Platform only.

Additional fields as `options`

There is a field called options available in all the components.

NOTE: There is a possibility to have two different values for a field.
An example: with a pre-defined field you can set value and the same field may be defined under options as well. In that case value from options will be final.

A sample options field,

options:
  disabled: false
  configMaps:
    config-leader-election: # name of the configMap
      data:
        lease-duration: "90s"
    pipeline-config-logging: # creates new configMap under targetNamespace
      metadata:
        labels:
          my-custom-logger: "true"
        annotations:
          logger-type: "uber-zap"
      data:
        loglevel.controller: "info"
        loglevel.webhook: "info"
        zap-logger-config: |
          {
            "level": "debug",
            "development": false,
            "sampling": {
              "initial": 100,
              "thereafter": 50
            },
            "outputPaths": ["stdout"],
            "errorOutputPaths": ["stderr"],
            "encoding": "json",
            "encoderConfig": {
              "timeKey": "ts",
              "levelKey": "severity",
              "nameKey": "logger",
              "callerKey": "caller",
              "messageKey": "message",
              "stacktraceKey": "stacktrace",
              "lineEnding": "",
              "levelEncoder": "",
              "timeEncoder": "iso8601",
              "durationEncoder": "",
              "callerEncoder": ""
            }
          }          

  deployments:
    tekton-pipelines-controller: # name of the deployment
      metadata:
        labels:
          custom-label: "foo"
        annotations:
          custom-annotation: "foo"
      spec:
        replicas: 2
        template:
          spec:
            containers:
              - name: tekton-pipelines-controller
                env:
                  - name: CONFIG_LOGGING_NAME
                    value: pipeline-config-logging
  statefulSets:
    web: # name of the statefulSets
      metadata:
        labels:
          custom-label: foo
        annotations:
          custom-annotation: foo
      spec:
        replicas: 3
        template:
          spec:
            containers:
              - name: nginx
                env:
                  - name: NGINX_MODE
                    value: production
  horizontalPodAutoscalers:
    tekton-pipelines-webhook: # name of the hpa
      metadata:
        annotations:
        labels:
      spec:
        minReplicas: 2
        maxReplicas: 7
        metrics:
        - resource:
            name: cpu
            target:
              averageUtilization: 85
              type: Utilization
          type: Resource
  webhookConfigurationOptions:
    validation.webhook.pipeline.tekton.dev:
      failurePolicy: Fail
      timeoutSeconds: 20
      sideEffects: None
    webhook.pipeline.tekton.dev:
      failurePolicy: Fail
      timeoutSeconds: 20
      sideEffects: None

disabled - disables the additional options support, if disabled set to true. default: false

ConfigMaps

Supports to update existing configMap also supports to create new configMap.

The following fields are supported in configMap

metadata
- labels - supports add and update
- annotations - supports add and update
data - supports add and update

Deployments

Supports to update the existing deployments. But not supported to create new deployment.

The following fields are supported in deployment

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- replicas - updates deployment replicas count
- template
  - metadata
    - labels - supports add and update
    - annotations - supports add and update
  - spec
    - affinity - replaces the existing Affinity with this, if not empty
    - priorityClassName - replaces the existing PriorityClassName with this, if not empty
    - nodeSelector - replaces the existing NodeSelector with this, if not empty
    - tolerations - replaces the existing tolerations with this, if not empty
    - topologySpreadConstraints - replaces the existing TopologySpreadConstraints with this, if not empty
    - runtimeClassName - adds and updates runtimeClassName
    - volumes - adds and updates volumes
    - initContainers - adds and updates init-containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS
    - containers - adds and updates containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS

StatefulSets

Supports to update the existing StatefulSet. But not supported to create new StatefulSet.

The following fields are supported in StatefulSet

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- replicas - updates statefulSets replicas count
- serviceName - updates service name
- podManagementPolicy - updates pod management policy
- volumeClaimTemplates - updates volume claim templates
- template
  - metadata
    - labels - supports add and update
    - annotations - supports add and update
  - spec
    - affinity - replaces the existing Affinity with this, if not empty
    - priorityClassName - replaces the existing PriorityClassName with this, if not empty
    - nodeSelector - replaces the existing NodeSelector with this, if not empty
    - tolerations - replaces the existing tolerations with this, if not empty
    - topologySpreadConstraints - replaces the existing TopologySpreadConstraints with this, if not empty
    - runtimeClassName - adds and updates runtimeClassName
    - volumes - adds and updates volumes
    - initContainers - adds and updates init-containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS
    - containers - adds and updates containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS

HorizontalPodAutoscalers

Supports to update the existing HorizontalPodAutoscaler(HPA) also supports to create new HPA.

The following fields are supported in HorizontalPodAutoscaler (aka HPA)

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- scaleTargetRef - replaces scaleTargetRef with this, if kind and name are not empty
- minReplicas - updates minimum replicas count
- maxReplicas - updates maximum replicas count
- metrics - replaces the metrics details with this array, if not empty
- behavior - updates behavior data with this, if not empty
  - scaleUp - replaces scaleUp with this, if not empty
  - scaleDown - replaces scaleDown with this, if not empty

webhookConfigurationOptions

the following options are supported for webhookConfigurationOptions

failurePolicy - defines how unrecognized errors and timeout errors from the admission webhook are handled. Allowed values are Ignore or Fail
timeoutSeconds - allows configuring how long the API server should wait for a webhook to respond before treating the call as a failure.
sideEffects - indicates whether the webhook have a side effet. Allowed values are None, NoneOnDryRun, Unknown, or Some

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Config

TektonConfig custom resource is the top most component of the operator which allows user to install and customize all other components at a single place.

Operator provides support for installing and managing following operator components through TektonConfig:

Other than the above components depending on the platform operator also provides support for

On both Kubernetes and OpenShift
- TektonChain
- TektonResult
On Kubernetes
- TektonDashboard
On OpenShift
- TektonAddon
- OpenShiftPipelinesAsCode

The TektonConfig CR provides the following features

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  targetNamespace: tekton-pipelines
  targetNamespaceMetadata:
    labels: {}
    annotations: {}
  profile: all
  config:
    nodeSelector: <>
    tolerations: []
    priorityClassName: system-cluster-critical
  chain:
    disabled: false
  pipeline:
    await-sidecar-readiness: true
    coschedule: workspaces
    disable-affinity-assistant: false
    disable-creds-init: false
    disable-home-env-overwrite: true
    disable-working-directory-overwrite: true
    disable-inline-spec: "pipeline,pipelinerun,taskrun"
    enable-api-fields: beta
    enable-bundles-resolver: true
    enable-cel-in-whenexpression: false
    enable-cluster-resolver: true
    enable-custom-tasks: true
    enable-git-resolver: true
    enable-hub-resolver: true
    enable-param-enum: false
    enable-provenance-in-status: true
    enable-step-actions: false
    enforce-nonfalsifiability: none
    keep-pod-on-cancel: false
    max-result-size: 4096
    metrics.count.enable-reason: false
    metrics.pipelinerun.duration-type: histogram
    metrics.pipelinerun.level: pipeline
    metrics.taskrun.duration-type: histogram
    metrics.taskrun.level: task
    require-git-ssh-secret-known-hosts: false
    results-from: termination-message
    running-in-environment-with-injected-sidecars: true
    send-cloudevents-for-runs: false
    set-security-context: false
    trusted-resources-verification-no-match-policy: ignore
    performance:
      disable-ha: false
      buckets: 1
      replicas: 1
      threads-per-controller: 2
      kube-api-qps: 5.0
      kube-api-burst: 10
    options:
      disabled: false
      configMaps: {}
      deployments: {}
      webhookConfigurationOptions: {}
  pruner:
    disabled: false
    schedule: "0 8 * * *"
    resources:
      - taskrun
      - pipelinerun
    keep: 3
    # keep-since: 1440
    # NOTE: you can use either "keep" or "keep-since", not both
    prune-per-resource: true
  hub:
    params:
      - name: enable-devconsole-integration
        value: "true"
    options:
      disabled: false
      configMaps: {}
      deployments: {}
      webhookConfigurationOptions: {}
  dashboard:
    readonly: true
    options:
      disabled: false
      configMaps: {}
      deployments: {}
      webhookConfigurationOptions: {}
  result:
    disabled: false
    is_external_db: false
    options: {}
    performance:
      disable-ha: false
      buckets: 1
      replicas: 1
platforms:
    openshift:
      pipelinesAsCode:
        additionalPACControllers:
          <controllerName>:
            enable: true
            configMapName:
            secretName:
            settings:
        enable: true
        settings:
          application-name: Pipelines as Code CI
          auto-configure-new-github-repo: "false"
          bitbucket-cloud-check-source-ip: "true"
          custom-console-name: ""
          custom-console-url: ""
          custom-console-url-pr-details: ""
          custom-console-url-pr-tasklog: ""
          error-detection-from-container-logs: "false"
          error-detection-max-number-of-lines: "50"
          error-detection-simple-regexp:
            ^(?P<filename>[^:]*):(?P<line>[0-9]+):(?P<column>[0-9]+):([
            ]*)?(?P<error>.*)
          error-log-snippet: "true"
          enable-cancel-in-progress-on-pull-requests: "false"
          enable-cancel-in-progress-on-push: "false"
          hub-catalog-name: tekton
          hub-url: https://api.hub.tekton.dev/v1
          skip-push-event-for-pr-commits: "true"
          remote-tasks: "true"
          secret-auto-create: "true"
          secret-github-app-token-scoped: "true"
      options:
        disabled: false
        configMaps: {}
        deployments: {}
        webhookConfigurationOptions: {}

Look for the particular section to understand a particular field in the spec.

Target Namespace

This allows user to choose a namespace to install the Tekton Components such as pipelines, triggers.

By default, namespace would be tekton-pipelines for Kubernetes and openshift-pipelines for OpenShift.

Note: Namespace openshift-operators is not allowed in OpenShift as a targetNamespace.

Target Namespace Metadata

targetNamespaceMetadata allows user to add their custom labels and annotations to the target namespace via TektonConfig CR.

Profile

This allows user to choose which all components to install on the cluster. There are 3 profiles available:

all: This profile will install all components (TektonPipeline, TektonTrigger, TektonResult and TektonChain)
basic: This profile will install only TektonPipeline, TektonTrigger, TektonResult and TektonChain component
lite: This profile will install only TektonPipeline component

On Kubernetes, all profile will install TektonDashboard and on OpenShift TektonAddon will be installed.

Config

Config provides fields to configure deployments created by the Operator. This provides following fields:

User can pass the required fields and this would be passed to all Operator components which will get added in all deployments created by Operator.

Example:

config:
  nodeSelector:
    key: value
  tolerations:
    - key: "key1"
      operator: "Equal"
      value: "value1"
      effect: "NoSchedule"
  priorityClassName: system-node-critical

This is an Optional section.

NOTE: If spec.config.priorityClassName is used, then the required priorityClass is expected to be created by the user to get the Tekton resources pods in running state

Pipeline

Pipeline section allows user to customize the Tekton pipeline features. This allow user to customize the values in configmaps.

Refer to properties section in TektonPipeline for available options.

Example:

pipeline:
  disable-affinity-assistant: false
  disable-creds-init: false
  disable-home-env-overwrite: true
  disable-working-directory-overwrite: true
  enable-api-fields: stable
  enable-custom-tasks: false
  metrics.pipelinerun.duration-type: histogram
  metrics.pipelinerun.level: pipelinerun
  metrics.taskrun.duration-type: histogram
  metrics.taskrun.level: taskrun
  require-git-ssh-secret-known-hosts: false
  running-in-environment-with-injected-sidecars: true
  trusted-resources-verification-no-match-policy: ignore
  performance:
    replicas: 1
    disable-ha: false
    buckets: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10

Chain

Chain section allows user to customize the Tekton Chain features. This allows user to customize the values in configmaps

Refer to properties section in TektonChain for available options

Example:

chain:
  disabled: false # - `disabled` : if the value set as `true`, chains feature will be disabled (default: `false`)
  targetNamespace: tekton-pipelines
  generateSigningSecret: true # default value: false
  controllerEnvs:
    - name: MONGO_SERVER_URL # This is the only field supported at the moment which is optional and when added by user, it is added as env to Chains controller
      value: #value               # This can be provided same as env field of container
  artifacts.taskrun.format: in-toto
  artifacts.taskrun.storage: tekton,oci (comma separated values)
  artifacts.taskrun.signer: x509
  artifacts.oci.storage: oci (comma separated values)
  artifacts.oci.format: simplesigning
  artifacts.oci.signer: x509
  artifacts.pipelinerun.format: in-toto
  artifacts.pipelinerun.storage: tekton,oci (comma separated values)
  artifacts.pipelinerun.signer: x509
  storage.gcs.bucket: #value
  storage.oci.repository: #value
  storage.oci.repository.insecure: #value (boolean - true/false)
  storage.docdb.url: #value
  storage.grafeas.projectid: #value
  storage.grafeas.noteid: #value
  storage.grafeas.notehint: #value
  builder.id: #value
  signers.x509.fulcio.enabled: #value (boolean - true/false)
  signers.x509.fulcio.address: #value
  signers.x509.fulcio.issuer: #value
  signers.x509.fulcio.provider: #value
  signers.x509.identity.token.file: #value
  signers.x509.tuf.mirror.url: #value
  signers.kms.kmsref: #value
  signers.kms.kmsref.auth.address: #value
  signers.kms.kmsref.auth.token: #value
  signers.kms.kmsref.auth.oidc.path: #value
  signers.kms.kmsref.auth.oidc.role: #value
  signers.kms.kmsref.auth.spire.sock: #value
  signers.kms.kmsref.auth.spire.audience: #value
  transparency.enabled: #value (boolean - true/false)
  transparency.url: #value

Result

Result section allows user to customize the Tekton Result component, Refer to Result Spec section in TektonResult for available options.

Default Result configuration in TektonConfig looks like following if user doesn’t specified any configuration options

Example:

result:
  disabled: false
  is_external_db: false
  options: {}

User can customize Result configuration with following options

Example:

result:
  disabled: false # - `disabled` : if the value set as `true`, result component will be disabled (default: `false`)
  targetNamespace: tekton-pipelines
  is_external_db: false # By default, this is set to false, TektonOperator will create Tekton Results database. If set to true, an external database will be used, and Tekton Results will retrieve its database credentials from the Kubernetes secret named tekton-results-postgres
  db_host: localhost
  db_port: 5342
  db_sslmode: verify-full
  db_sslrootcert: /etc/tls/db/ca.crt
  db_enable_auto_migration: true
  log_level: debug
  logs_api: true
  logs_type: File
  logs_buffer_size: 90kb
  logs_path: /logs
  auth_disable: true
  logging_pvc_name: tekton-logs
  secret_name: # optional
  gcs_creds_secret_name: <value>
  gcc_creds_secret_key: <value>
  gcs_bucket_name: <value>
  loki_stack_name: #optional
  loki_stack_namespace: #optional
  prometheus_port: 9090
  prometheus_histogram: false

User can configure custom database secret name for internal/external database via Tekton Config CR.

Example:

result:
  db_secret_name: # custom database secret name
  db_secret_user_key: # optional: required if custom database secret user key is not "POSTGRES_USER"
  db_secret_password_key: # optional: required if custom database secret password key is not "POSTGRES_PASSWORD"

Pruner

Pruner provides auto clean up feature for the Tekton pipelinerun and taskrun resources. In the background pruner container runs tkn command.

Example:

pruner:
  disabled: false
  schedule: "0 8 * * *"
  startingDeadlineSeconds: 100 # optional
  resources:
    - taskrun
    - pipelinerun
  keep: 3
  # keep-since: 1440
  # NOTE: you can use either "keep" or "keep-since", not both
  prune-per-resource: true

disabled : if the value set as true, pruner feature will be disabled (default: false)
schedule: how often to run the pruner job. User can understand the schedule syntax here.
startingDeadlineSeconds: Optional deadline in seconds for starting the job if it misses scheduled time for any reason. Missed jobs executions will be counted as failed ones
resources: supported resources for auto prune are taskrun and pipelinerun
keep: maximum number of resources to keep while deleting or removing resources
keep-since: retain the resources younger than the specified value in minutes
prune-per-resource: if the value set as true (default value false), the keep applied to each resource. The resources(pipeline and/or task) taken dynamically from that namespace and applied.
example: in a namespace ns-1 I have two pipeline, named pipeline-1 and pipeline-2, the out come would be: tkn pipelinerun delete --pipeline=my-pipeline-1 --keep=3 --namespace=ns-1, tkn pipelinerun delete --pipeline=my-pipeline-2 --keep=3 --namespace=ns-1. the same way works for task too.
We do not see any benefit by enabling prune-per-resource=true, when you use keep-since. As keep-since is limiting the resources by time(irrespective of resource count), there is no change on the outcome.

Note:

if disabled: false and schedule: with empty value, global pruner job will be disabled. however, if there is a prune schedule (operator.tekton.dev/prune.schedule) annotation present with a value in a namespace. a namespace wide pruner jobs will be created.

Pruner Namespace annotations

operator.tekton.dev/prune.skip - pruner job will be skipped to a namespace, if the value set as true
operator.tekton.dev/prune.schedule - pruner job will be created on a specific schedule
operator.tekton.dev/prune.keep - maximum number of resources will be kept
operator.tekton.dev/prune.keep-since - retain the resources younger than the specified value in minutes
operator.tekton.dev/prune.prune-per-resource - the keep or keep-since applied to each resource
operator.tekton.dev/prune.resources - can be taskrun and/or pipelinerun, both value can be specified with comma separated. example: taskrun,pipelinerun
operator.tekton.dev/prune.strategy - allowed values: either keep or keep-since

Note:

if a global value is not present the following values will be consider as default value
> resources: pipelinerun
> keep: 100

Addon

TektonAddon install some resources along with Tekton Pipelines on the cluster. This provides few PipelineTemplates, ResolverTasks, ResolverStepActions and CommunityResolverTasks.

This section allows to customize installation of those resources through params. You can read more about the supported params here.

Example:

addon:
  params:
    - name: "pipelineTemplates"
      value: "true"
    - name: "resolverTasks"
      value: "true"
    - name: "resolverStepActions"
      value: "true"
    - name: "communityResolverTasks"
      value: "true"

NOTE: TektonAddon is currently available for OpenShift Platform only. Enabling this for Kubernetes platform is in roadmap of Operator.

Hub

Example:

hub:
  params:
    - name: enable-devconsole-integration
      value: "false"

Dashboard

Dashboard provides configuration options for the Tekton Dashboard if the specified profile value includes the Dashboard component. (E.g. all on Kubernetes)

Example:

dashboard:
  readonly: true

readonly: If set to true, install the Dashboard in read-only mode

This is an Optional section.

Resolvers

As part of TektonPipelines, resolvers are installed which are by default enabled. User can disable them through TektonConfig.

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    enable-bundles-resolver: true
    enable-cluster-resolver: true
    enable-git-resolver: true
    enable-hub-resolver: true

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    bundles-resolver-config:
      default-service-account: pipelines
    cluster-resolver-config:
      default-namespace: cluster-resolver-test
    enable-bundles-resolver: true
    enable-cluster-resolver: true
    enable-git-resolver: true
    enable-hub-resolver: true
    git-resolver-config:
      server-url: localhost.com
    hub-resolver-config:
      default-tekton-hub-catalog: tekton
      tekton-hub-api: "https://my-custom-tekton-hub.example.com"
      artifact-hub-api: "https://my-custom-artifact-hub.example.com"

tekton-hub-api => TEKTON_HUB_API
artifact-hub-api => ARTIFACT_HUB_API

OpenShiftPipelinesAsCode

Example:

platforms:
  openshift:
    pipelinesAsCode:
      additionalPACControllers:
        controllername:
          enable: true
          configMapName:
          secretName:
          settings:
      enable: true
      settings:
        application-name: Pipelines as Code CI
        auto-configure-new-github-repo: "false"
        bitbucket-cloud-check-source-ip: "true"
        custom-console-name: ""
        custom-console-url: ""
        custom-console-url-pr-details: ""
        custom-console-url-pr-tasklog: ""
        error-detection-from-container-logs: "false"
        error-detection-max-number-of-lines: "50"
        error-detection-simple-regexp:
          ^(?P<filename>[^:]*):(?P<line>[0-9]+):(?P<column>[0-9]+):([
          ]*)?(?P<error>.*)
        error-log-snippet: "true"
        enable-cancel-in-progress-on-pull-requests: "false"
        enable-cancel-in-progress-on-push: "false"
        hub-catalog-name: tekton
        hub-url: https://api.hub.tekton.dev/v1
        remote-tasks: "true"
        secret-auto-create: "true"
        secret-github-app-token-scoped: "true"

NOTE: OpenShiftPipelinesAsCode is currently available for the OpenShift Platform only.

Tech Preview Event based pruner

The tektonpruner section in the TektonConfig spec allows to manage the event-driven Tekton Pruner, which enables configuration-based cleanup of Tekton resources.

Important: This component is disabled by default. To enable the event-based pruner, the existing job-based pruner pruner MUST be disabled.

  tektonpruner:
    disabled: true
    options: {}

Configuration Notes :

In this Tech Preview, only enabled/disabled status is configurable via tektonconfig spec.
For all other configurations(e.g., TTLs, history limits), use the ConfigMap: tekton-pruner-default-spec

Additional fields as `options`

There is a field called options available in all the components.

NOTE: There is a possibility to have two different values for a field.
An example: with a pre-defined field you can set value and the same field may be defined under options as well. In that case value from options will be final.

A sample options field,

options:
  disabled: false
  configMaps:
    config-leader-election: # name of the configMap
      data:
        lease-duration: "90s"
    pipeline-config-logging: # creates new configMap under targetNamespace
      metadata:
        labels:
          my-custom-logger: "true"
        annotations:
          logger-type: "uber-zap"
      data:
        loglevel.controller: "info"
        loglevel.webhook: "info"
        zap-logger-config: |
          {
            "level": "debug",
            "development": false,
            "sampling": {
              "initial": 100,
              "thereafter": 50
            },
            "outputPaths": ["stdout"],
            "errorOutputPaths": ["stderr"],
            "encoding": "json",
            "encoderConfig": {
              "timeKey": "ts",
              "levelKey": "severity",
              "nameKey": "logger",
              "callerKey": "caller",
              "messageKey": "message",
              "stacktraceKey": "stacktrace",
              "lineEnding": "",
              "levelEncoder": "",
              "timeEncoder": "iso8601",
              "durationEncoder": "",
              "callerEncoder": ""
            }
          }          

  deployments:
    tekton-pipelines-controller: # name of the deployment
      metadata:
        labels:
          custom-label: "foo"
        annotations:
          custom-annotation: "foo"
      spec:
        replicas: 2
        template:
          spec:
            containers:
              - name: tekton-pipelines-controller
                env:
                  - name: CONFIG_LOGGING_NAME
                    value: pipeline-config-logging
  statefulSets:
    web: # name of the statefulSets
      metadata:
        labels:
          custom-label: foo
        annotations:
          custom-annotation: foo
      spec:
        replicas: 3
        template:
          spec:
            containers:
              - name: nginx
                env:
                  - name: NGINX_MODE
                    value: production
  horizontalPodAutoscalers:
    tekton-pipelines-webhook: # name of the hpa
      metadata:
        annotations:
        labels:
      spec:
        minReplicas: 2
        maxReplicas: 7
        metrics:
          - resource:
              name: cpu
              target:
                averageUtilization: 85
                type: Utilization
            type: Resource
  webhookConfigurationOptions:
    validation.webhook.pipeline.tekton.dev:
      failurePolicy: Fail
      timeoutSeconds: 20
      sideEffects: None
    webhook.pipeline.tekton.dev:
      failurePolicy: Fail
      timeoutSeconds: 20
      sideEffects: None

disabled - disables the additional options support, if disabled set to true. default: false

ConfigMaps

Supports to update existing configMap also supports to create new configMap.

The following fields are supported in configMap

metadata
- labels - supports add and update
- annotations - supports add and update
data - supports add and update

Deployments

Supports to update the existing deployments. But not supported to create new deployment.

The following fields are supported in deployment

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- replicas - updates deployment replicas count
- template
  - metadata
    - labels - supports add and update
    - annotations - supports add and update
  - spec
    - affinity - replaces the existing Affinity with this, if not empty
    - priorityClassName - replaces the existing PriorityClassName with this, if not empty
    - nodeSelector - replaces the existing NodeSelector with this, if not empty
    - tolerations - replaces the existing tolerations with this, if not empty
    - topologySpreadConstraints - replaces the existing TopologySpreadConstraints with this, if not empty
    - runtimeClassName - adds and updates runtimeClassName
    - volumes - adds and updates volumes
    - initContainers - adds and updates init-containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS
    - containers - adds and updates containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS

StatefulSets

Supports to update the existing StatefulSet. But not supported to create new StatefulSet.

The following fields are supported in StatefulSet

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- replicas - updates statefulSets replicas count
- serviceName - updates service name
- podManagementPolicy - updates pod management policy
- volumeClaimTemplates - updates volume claim templates
- template
  - metadata
    - labels - supports add and update
    - annotations - supports add and update
  - spec
    - affinity - replaces the existing Affinity with this, if not empty
    - priorityClassName - replaces the existing PriorityClassName with this, if not empty
    - nodeSelector - replaces the existing NodeSelector with this, if not empty
    - tolerations - replaces the existing tolerations with this, if not empty
    - topologySpreadConstraints - replaces the existing TopologySpreadConstraints with this, if not empty
    - runtimeClassName - adds and updates runtimeClassName
    - volumes - adds and updates volumes
    - initContainers - adds and updates init-containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS
    - containers - adds and updates containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS

HorizontalPodAutoscalers

Supports to update the existing HorizontalPodAutoscaler(HPA) also supports to create new HPA.

The following fields are supported in HorizontalPodAutoscaler (aka HPA)

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- scaleTargetRef - replaces scaleTargetRef with this, if kind and name are not empty
- minReplicas - updates minimum replicas count
- maxReplicas - updates maximum replicas count
- metrics - replaces the metrics details with this array, if not empty
- behavior - updates behavior data with this, if not empty
  - scaleUp - replaces scaleUp with this, if not empty
  - scaleDown - replaces scaleDown with this, if not empty

webhookConfigurationOptions

the following options are supported for webhookConfigurationOptions

failurePolicy - defines how unrecognized errors and timeout errors from the admission webhook are handled. Allowed values are Ignore or Fail
timeoutSeconds - allows configuring how long the API server should wait for a webhook to respond before treating the call as a failure.
sideEffects - indicates whether the webhook have a side effet. Allowed values are None, NoneOnDryRun, Unknown, or Some

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Config

TektonConfig custom resource is the top most component of the operator which allows user to install and customize all other components at a single place.

Operator provides support for installing and managing following operator components through TektonConfig:

Other than the above components depending on the platform operator also provides support for

On both Kubernetes and OpenShift
- TektonChain
- TektonResult
On Kubernetes
- TektonDashboard
On OpenShift
- TektonAddon
- OpenShiftPipelinesAsCode

The TektonConfig CR provides the following features

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  targetNamespace: tekton-pipelines
  targetNamespaceMetadata:
    labels: {}
    annotations: {}
  profile: all
  config:
    nodeSelector: <>
    tolerations: []
    priorityClassName: system-cluster-critical
  chain:
    disabled: false
  pipeline:
    await-sidecar-readiness: true
    coschedule: workspaces
    disable-affinity-assistant: false
    disable-creds-init: false
    disable-home-env-overwrite: true
    disable-working-directory-overwrite: true
    disable-inline-spec: "pipeline,pipelinerun,taskrun"
    enable-api-fields: beta
    enable-bundles-resolver: true
    enable-cel-in-whenexpression: false
    enable-cluster-resolver: true
    enable-custom-tasks: true
    enable-git-resolver: true
    enable-hub-resolver: true
    enable-param-enum: false
    enable-provenance-in-status: true
    enable-step-actions: false
    enforce-nonfalsifiability: none
    keep-pod-on-cancel: false
    max-result-size: 4096
    metrics.count.enable-reason: false
    metrics.pipelinerun.duration-type: histogram
    metrics.pipelinerun.level: pipeline
    metrics.taskrun.duration-type: histogram
    metrics.taskrun.level: task
    require-git-ssh-secret-known-hosts: false
    results-from: termination-message
    running-in-environment-with-injected-sidecars: true
    send-cloudevents-for-runs: false
    set-security-context: false
    trusted-resources-verification-no-match-policy: ignore
    performance:
      disable-ha: false
      buckets: 1
      replicas: 1
      threads-per-controller: 2
      kube-api-qps: 5.0
      kube-api-burst: 10
    options:
      disabled: false
      configMaps: {}
      deployments: {}
      webhookConfigurationOptions: {}
  pruner:
    disabled: false
    schedule: "0 8 * * *"
    resources:
      - taskrun
      - pipelinerun
    keep: 3
    # keep-since: 1440
    # NOTE: you can use either "keep" or "keep-since", not both
    prune-per-resource: true
  hub:
    params:
      - name: enable-devconsole-integration
        value: "true"
    options:
      disabled: false
      configMaps: {}
      deployments: {}
      webhookConfigurationOptions: {}
  dashboard:
    readonly: true
    options:
      disabled: false
      configMaps: {}
      deployments: {}
      webhookConfigurationOptions: {}
  result:
    disabled: false
    is_external_db: false
    options: {}
    performance:
      disable-ha: false
      buckets: 1
      replicas: 1
  trigger:
    disabled: false
platforms:
    openshift:
      pipelinesAsCode:
        additionalPACControllers:
          <controllerName>:
            enable: true
            configMapName:
            secretName:
            settings:
        enable: true
        settings:
          application-name: Pipelines as Code CI
          auto-configure-new-github-repo: "false"
          bitbucket-cloud-check-source-ip: "true"
          custom-console-name: ""
          custom-console-url: ""
          custom-console-url-pr-details: ""
          custom-console-url-pr-tasklog: ""
          error-detection-from-container-logs: "false"
          error-detection-max-number-of-lines: "50"
          error-detection-simple-regexp:
            ^(?P<filename>[^:]*):(?P<line>[0-9]+):(?P<column>[0-9]+):([
            ]*)?(?P<error>.*)
          error-log-snippet: "true"
          enable-cancel-in-progress-on-pull-requests: "false"
          enable-cancel-in-progress-on-push: "false"
          hub-catalog-name: tekton
          hub-url: https://api.hub.tekton.dev/v1
          skip-push-event-for-pr-commits: "true"
          remote-tasks: "true"
          secret-auto-create: "true"
          secret-github-app-token-scoped: "true"
      options:
        disabled: false
        configMaps: {}
        deployments: {}
        webhookConfigurationOptions: {}

Look for the particular section to understand a particular field in the spec.

Target Namespace

This allows user to choose a namespace to install the Tekton Components such as pipelines, triggers.

By default, namespace would be tekton-pipelines for Kubernetes and openshift-pipelines for OpenShift.

Note: Namespace openshift-operators is not allowed in OpenShift as a targetNamespace.

Target Namespace Metadata

targetNamespaceMetadata allows user to add their custom labels and annotations to the target namespace via TektonConfig CR.

Profile

This allows user to choose which all components to install on the cluster. There are 3 profiles available:

all: This profile will install all components (TektonPipeline, TektonTrigger, TektonResult and TektonChain)
basic: This profile will install only TektonPipeline, TektonTrigger, TektonResult and TektonChain component
lite: This profile will install only TektonPipeline component

On Kubernetes, all profile will install TektonDashboard and on OpenShift TektonAddon will be installed.

Config

Config provides fields to configure deployments created by the Operator. This provides following fields:

User can pass the required fields and this would be passed to all Operator components which will get added in all deployments created by Operator.

Example:

config:
  nodeSelector:
    key: value
  tolerations:
    - key: "key1"
      operator: "Equal"
      value: "value1"
      effect: "NoSchedule"
  priorityClassName: system-node-critical

This is an Optional section.

NOTE: If spec.config.priorityClassName is used, then the required priorityClass is expected to be created by the user to get the Tekton resources pods in running state

Pipeline

Pipeline section allows user to customize the Tekton pipeline features. This allow user to customize the values in configmaps.

Refer to properties section in TektonPipeline for available options.

Example:

pipeline:
  disable-affinity-assistant: false
  disable-creds-init: false
  disable-home-env-overwrite: true
  disable-working-directory-overwrite: true
  enable-api-fields: stable
  enable-custom-tasks: false
  metrics.pipelinerun.duration-type: histogram
  metrics.pipelinerun.level: pipelinerun
  metrics.taskrun.duration-type: histogram
  metrics.taskrun.level: taskrun
  require-git-ssh-secret-known-hosts: false
  running-in-environment-with-injected-sidecars: true
  trusted-resources-verification-no-match-policy: ignore
  performance:
    replicas: 1
    disable-ha: false
    buckets: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10

Chain

Chain section allows user to customize the Tekton Chain features. This allows user to customize the values in configmaps

Refer to properties section in TektonChain for available options

Example:

chain:
  disabled: false # - `disabled` : if the value set as `true`, chains feature will be disabled (default: `false`)
  targetNamespace: tekton-pipelines
  generateSigningSecret: true # default value: false
  controllerEnvs:
    - name: MONGO_SERVER_URL # This is the only field supported at the moment which is optional and when added by user, it is added as env to Chains controller
      value: #value               # This can be provided same as env field of container
  artifacts.taskrun.format: in-toto
  artifacts.taskrun.storage: tekton,oci (comma separated values)
  artifacts.taskrun.signer: x509
  artifacts.oci.storage: oci (comma separated values)
  artifacts.oci.format: simplesigning
  artifacts.oci.signer: x509
  artifacts.pipelinerun.format: in-toto
  artifacts.pipelinerun.storage: tekton,oci (comma separated values)
  artifacts.pipelinerun.signer: x509
  storage.gcs.bucket: #value
  storage.oci.repository: #value
  storage.oci.repository.insecure: #value (boolean - true/false)
  storage.docdb.url: #value
  storage.grafeas.projectid: #value
  storage.grafeas.noteid: #value
  storage.grafeas.notehint: #value
  builder.id: #value
  signers.x509.fulcio.enabled: #value (boolean - true/false)
  signers.x509.fulcio.address: #value
  signers.x509.fulcio.issuer: #value
  signers.x509.fulcio.provider: #value
  signers.x509.identity.token.file: #value
  signers.x509.tuf.mirror.url: #value
  signers.kms.kmsref: #value
  signers.kms.kmsref.auth.address: #value
  signers.kms.kmsref.auth.token: #value
  signers.kms.kmsref.auth.oidc.path: #value
  signers.kms.kmsref.auth.oidc.role: #value
  signers.kms.kmsref.auth.spire.sock: #value
  signers.kms.kmsref.auth.spire.audience: #value
  transparency.enabled: #value (boolean - true/false)
  transparency.url: #value

Result

Result section allows user to customize the Tekton Result component, Refer to Result Spec section in TektonResult for available options.

Default Result configuration in TektonConfig looks like following if user doesn’t specified any configuration options

Example:

result:
  disabled: false
  is_external_db: false
  options: {}

User can customize Result configuration with following options

Example:

result:
  disabled: false # - `disabled` : if the value set as `true`, result component will be disabled (default: `false`)
  targetNamespace: tekton-pipelines
  is_external_db: false # By default, this is set to false, TektonOperator will create Tekton Results database. If set to true, an external database will be used, and Tekton Results will retrieve its database credentials from the Kubernetes secret named tekton-results-postgres
  db_host: localhost
  db_port: 5342
  db_sslmode: verify-full
  db_sslrootcert: /etc/tls/db/ca.crt
  db_enable_auto_migration: true
  log_level: debug
  logs_api: true
  logs_type: File
  logs_buffer_size: 90kb
  logs_path: /logs
  auth_disable: true
  logging_pvc_name: tekton-logs
  secret_name: # optional
  gcs_creds_secret_name: <value>
  gcc_creds_secret_key: <value>
  gcs_bucket_name: <value>
  loki_stack_name: #optional
  loki_stack_namespace: #optional
  prometheus_port: 9090
  prometheus_histogram: false

User can configure custom database secret name for internal/external database via Tekton Config CR.

Example:

result:
  db_secret_name: # custom database secret name
  db_secret_user_key: # optional: required if custom database secret user key is not "POSTGRES_USER"
  db_secret_password_key: # optional: required if custom database secret password key is not "POSTGRES_PASSWORD"

Pruner

Pruner provides auto clean up feature for the Tekton pipelinerun and taskrun resources. In the background pruner container runs tkn command.

Example:

pruner:
  disabled: false
  schedule: "0 8 * * *"
  startingDeadlineSeconds: 100 # optional
  resources:
    - taskrun
    - pipelinerun
  keep: 3
  # keep-since: 1440
  # NOTE: you can use either "keep" or "keep-since", not both
  prune-per-resource: true

disabled : if the value set as true, pruner feature will be disabled (default: false)
schedule: how often to run the pruner job. User can understand the schedule syntax here.
startingDeadlineSeconds: Optional deadline in seconds for starting the job if it misses scheduled time for any reason. Missed jobs executions will be counted as failed ones
resources: supported resources for auto prune are taskrun and pipelinerun
keep: maximum number of resources to keep while deleting or removing resources
keep-since: retain the resources younger than the specified value in minutes
prune-per-resource: if the value set as true (default value false), the keep applied to each resource. The resources(pipeline and/or task) taken dynamically from that namespace and applied.
example: in a namespace ns-1 I have two pipeline, named pipeline-1 and pipeline-2, the out come would be: tkn pipelinerun delete --pipeline=my-pipeline-1 --keep=3 --namespace=ns-1, tkn pipelinerun delete --pipeline=my-pipeline-2 --keep=3 --namespace=ns-1. the same way works for task too.
We do not see any benefit by enabling prune-per-resource=true, when you use keep-since. As keep-since is limiting the resources by time(irrespective of resource count), there is no change on the outcome.

Note:

if disabled: false and schedule: with empty value, global pruner job will be disabled. however, if there is a prune schedule (operator.tekton.dev/prune.schedule) annotation present with a value in a namespace. a namespace wide pruner jobs will be created.

Pruner Namespace annotations

operator.tekton.dev/prune.skip - pruner job will be skipped to a namespace, if the value set as true
operator.tekton.dev/prune.schedule - pruner job will be created on a specific schedule
operator.tekton.dev/prune.keep - maximum number of resources will be kept
operator.tekton.dev/prune.keep-since - retain the resources younger than the specified value in minutes
operator.tekton.dev/prune.prune-per-resource - the keep or keep-since applied to each resource
operator.tekton.dev/prune.resources - can be taskrun and/or pipelinerun, both value can be specified with comma separated. example: taskrun,pipelinerun
operator.tekton.dev/prune.strategy - allowed values: either keep or keep-since

Note:

if a global value is not present the following values will be consider as default value
> resources: pipelinerun
> keep: 100

Addon

TektonAddon install some resources along with Tekton Pipelines on the cluster. This provides few PipelineTemplates, ResolverTasks, ResolverStepActions and CommunityResolverTasks.

This section allows to customize installation of those resources through params. You can read more about the supported params here.

Example:

addon:
  params:
    - name: "pipelineTemplates"
      value: "true"
    - name: "resolverTasks"
      value: "true"
    - name: "resolverStepActions"
      value: "true"
    - name: "communityResolverTasks"
      value: "true"

NOTE: TektonAddon is currently available for OpenShift Platform only. Enabling this for Kubernetes platform is in roadmap of Operator.

Hub

Example:

hub:
  params:
    - name: enable-devconsole-integration
      value: "false"

Dashboard

Dashboard provides configuration options for the Tekton Dashboard if the specified profile value includes the Dashboard component. (E.g. all on Kubernetes)

Example:

dashboard:
  readonly: true

readonly: If set to true, install the Dashboard in read-only mode

This is an Optional section.

Resolvers

As part of TektonPipelines, resolvers are installed which are by default enabled. User can disable them through TektonConfig.

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    enable-bundles-resolver: true
    enable-cluster-resolver: true
    enable-git-resolver: true
    enable-hub-resolver: true

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    bundles-resolver-config:
      default-service-account: pipelines
    cluster-resolver-config:
      default-namespace: cluster-resolver-test
    enable-bundles-resolver: true
    enable-cluster-resolver: true
    enable-git-resolver: true
    enable-hub-resolver: true
    git-resolver-config:
      server-url: localhost.com
    hub-resolver-config:
      default-tekton-hub-catalog: tekton
      tekton-hub-api: "https://my-custom-tekton-hub.example.com"
      artifact-hub-api: "https://my-custom-artifact-hub.example.com"

tekton-hub-api => TEKTON_HUB_API
artifact-hub-api => ARTIFACT_HUB_API

OpenShiftPipelinesAsCode

Example:

platforms:
  openshift:
    pipelinesAsCode:
      additionalPACControllers:
        controllername:
          enable: true
          configMapName:
          secretName:
          settings:
      enable: true
      settings:
        application-name: Pipelines as Code CI
        auto-configure-new-github-repo: "false"
        bitbucket-cloud-check-source-ip: "true"
        custom-console-name: ""
        custom-console-url: ""
        custom-console-url-pr-details: ""
        custom-console-url-pr-tasklog: ""
        error-detection-from-container-logs: "false"
        error-detection-max-number-of-lines: "50"
        error-detection-simple-regexp:
          ^(?P<filename>[^:]*):(?P<line>[0-9]+):(?P<column>[0-9]+):([
          ]*)?(?P<error>.*)
        error-log-snippet: "true"
        enable-cancel-in-progress-on-pull-requests: "false"
        enable-cancel-in-progress-on-push: "false"
        hub-catalog-name: tekton
        hub-url: https://api.hub.tekton.dev/v1
        remote-tasks: "true"
        secret-auto-create: "true"
        secret-github-app-token-scoped: "true"

NOTE: OpenShiftPipelinesAsCode is currently available for the OpenShift Platform only.

Tech Preview Event based pruner

The tektonpruner section in the TektonConfig spec allows to manage the event-driven Tekton Pruner, which enables configuration-based cleanup of Tekton resources.

Important: This component is disabled by default. To enable the event-based pruner, the existing job-based pruner pruner MUST be disabled.

  tektonpruner:
    disabled: true
    options: {}

Configuration Notes :

In this Tech Preview, only enabled/disabled status is configurable via tektonconfig spec.
For all other configurations(e.g., TTLs, history limits), use the ConfigMap: tekton-pruner-default-spec

Additional fields as `options`

There is a field called options available in all the components.

NOTE: There is a possibility to have two different values for a field.
An example: with a pre-defined field you can set value and the same field may be defined under options as well. In that case value from options will be final.

A sample options field,

options:
  disabled: false
  configMaps:
    config-leader-election: # name of the configMap
      data:
        lease-duration: "90s"
    pipeline-config-logging: # creates new configMap under targetNamespace
      metadata:
        labels:
          my-custom-logger: "true"
        annotations:
          logger-type: "uber-zap"
      data:
        loglevel.controller: "info"
        loglevel.webhook: "info"
        zap-logger-config: |
          {
            "level": "debug",
            "development": false,
            "sampling": {
              "initial": 100,
              "thereafter": 50
            },
            "outputPaths": ["stdout"],
            "errorOutputPaths": ["stderr"],
            "encoding": "json",
            "encoderConfig": {
              "timeKey": "ts",
              "levelKey": "severity",
              "nameKey": "logger",
              "callerKey": "caller",
              "messageKey": "message",
              "stacktraceKey": "stacktrace",
              "lineEnding": "",
              "levelEncoder": "",
              "timeEncoder": "iso8601",
              "durationEncoder": "",
              "callerEncoder": ""
            }
          }          

  deployments:
    tekton-pipelines-controller: # name of the deployment
      metadata:
        labels:
          custom-label: "foo"
        annotations:
          custom-annotation: "foo"
      spec:
        replicas: 2
        template:
          spec:
            containers:
              - name: tekton-pipelines-controller
                env:
                  - name: CONFIG_LOGGING_NAME
                    value: pipeline-config-logging
  statefulSets:
    web: # name of the statefulSets
      metadata:
        labels:
          custom-label: foo
        annotations:
          custom-annotation: foo
      spec:
        replicas: 3
        template:
          spec:
            containers:
              - name: nginx
                env:
                  - name: NGINX_MODE
                    value: production
  horizontalPodAutoscalers:
    tekton-pipelines-webhook: # name of the hpa
      metadata:
        annotations:
        labels:
      spec:
        minReplicas: 2
        maxReplicas: 7
        metrics:
          - resource:
              name: cpu
              target:
                averageUtilization: 85
                type: Utilization
            type: Resource
  webhookConfigurationOptions:
    validation.webhook.pipeline.tekton.dev:
      failurePolicy: Fail
      timeoutSeconds: 20
      sideEffects: None
    webhook.pipeline.tekton.dev:
      failurePolicy: Fail
      timeoutSeconds: 20
      sideEffects: None

disabled - disables the additional options support, if disabled set to true. default: false

ConfigMaps

Supports to update existing configMap also supports to create new configMap.

The following fields are supported in configMap

metadata
- labels - supports add and update
- annotations - supports add and update
data - supports add and update

Deployments

Supports to update the existing deployments. But not supported to create new deployment.

The following fields are supported in deployment

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- replicas - updates deployment replicas count
- template
  - metadata
    - labels - supports add and update
    - annotations - supports add and update
  - spec
    - affinity - replaces the existing Affinity with this, if not empty
    - priorityClassName - replaces the existing PriorityClassName with this, if not empty
    - nodeSelector - replaces the existing NodeSelector with this, if not empty
    - tolerations - replaces the existing tolerations with this, if not empty
    - topologySpreadConstraints - replaces the existing TopologySpreadConstraints with this, if not empty
    - runtimeClassName - adds and updates runtimeClassName
    - volumes - adds and updates volumes
    - initContainers - adds and updates init-containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS
    - containers - adds and updates containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS

StatefulSets

Supports to update the existing StatefulSet. But not supported to create new StatefulSet.

The following fields are supported in StatefulSet

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- replicas - updates statefulSets replicas count
- serviceName - updates service name
- podManagementPolicy - updates pod management policy
- volumeClaimTemplates - updates volume claim templates
- template
  - metadata
    - labels - supports add and update
    - annotations - supports add and update
  - spec
    - affinity - replaces the existing Affinity with this, if not empty
    - priorityClassName - replaces the existing PriorityClassName with this, if not empty
    - nodeSelector - replaces the existing NodeSelector with this, if not empty
    - tolerations - replaces the existing tolerations with this, if not empty
    - topologySpreadConstraints - replaces the existing TopologySpreadConstraints with this, if not empty
    - runtimeClassName - adds and updates runtimeClassName
    - volumes - adds and updates volumes
    - initContainers - adds and updates init-containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS
    - containers - adds and updates containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS

HorizontalPodAutoscalers

Supports to update the existing HorizontalPodAutoscaler(HPA) also supports to create new HPA.

The following fields are supported in HorizontalPodAutoscaler (aka HPA)

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- scaleTargetRef - replaces scaleTargetRef with this, if kind and name are not empty
- minReplicas - updates minimum replicas count
- maxReplicas - updates maximum replicas count
- metrics - replaces the metrics details with this array, if not empty
- behavior - updates behavior data with this, if not empty
  - scaleUp - replaces scaleUp with this, if not empty
  - scaleDown - replaces scaleDown with this, if not empty

webhookConfigurationOptions

the following options are supported for webhookConfigurationOptions

failurePolicy - defines how unrecognized errors and timeout errors from the admission webhook are handled. Allowed values are Ignore or Fail
timeoutSeconds - allows configuring how long the API server should wait for a webhook to respond before treating the call as a failure.
sideEffects - indicates whether the webhook have a side effet. Allowed values are None, NoneOnDryRun, Unknown, or Some

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Config

TektonConfig custom resource is the top most component of the operator which allows user to install and customize all other components at a single place.

Operator provides support for installing and managing following operator components through TektonConfig:

Other than the above components depending on the platform operator also provides support for

On both Kubernetes and OpenShift
- TektonChain
- TektonResult
On Kubernetes
- TektonDashboard
On OpenShift
- TektonAddon
- OpenShiftPipelinesAsCode

The TektonConfig CR provides the following features

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  targetNamespace: tekton-pipelines
  targetNamespaceMetadata:
    labels: {}
    annotations: {}
  profile: all
  config:
    nodeSelector: <>
    tolerations: []
    priorityClassName: system-cluster-critical
  chain:
    disabled: false
  pipeline:
    await-sidecar-readiness: true
    coschedule: workspaces
    disable-affinity-assistant: false
    disable-creds-init: false
    disable-home-env-overwrite: true
    disable-working-directory-overwrite: true
    disable-inline-spec: "pipeline,pipelinerun,taskrun"
    enable-api-fields: beta
    enable-bundles-resolver: true
    enable-cel-in-whenexpression: false
    enable-cluster-resolver: true
    enable-custom-tasks: true
    enable-git-resolver: true
    enable-hub-resolver: true
    enable-param-enum: false
    enable-provenance-in-status: true
    enable-step-actions: false
    enforce-nonfalsifiability: none
    keep-pod-on-cancel: false
    max-result-size: 4096
    metrics.count.enable-reason: false
    metrics.pipelinerun.duration-type: histogram
    metrics.pipelinerun.level: pipeline
    metrics.taskrun.duration-type: histogram
    metrics.taskrun.level: task
    # Tracing configuration (optional)
    # traces.enabled: true
    # traces.endpoint: "http://jaeger-collector.jaeger.svc.cluster.local:4318/v1/traces"
    # traces.credentialsSecret: ""
    require-git-ssh-secret-known-hosts: false
    results-from: termination-message
    running-in-environment-with-injected-sidecars: true
    send-cloudevents-for-runs: false
    set-security-context: false
    trusted-resources-verification-no-match-policy: ignore
    performance:
      disable-ha: false
      buckets: 1
      replicas: 1
      threads-per-controller: 2
      kube-api-qps: 5.0
      kube-api-burst: 10
    options:
      disabled: false
      configMaps: {}
      deployments: {}
      webhookConfigurationOptions: {}
  pruner:
    disabled: false
    schedule: "0 8 * * *"
    resources:
      - taskrun
      - pipelinerun
    keep: 3
    # keep-since: 1440
    # NOTE: you can use either "keep" or "keep-since", not both
    prune-per-resource: true
  hub:
    params:
      - name: enable-devconsole-integration
        value: "true"
    options:
      disabled: false
      configMaps: {}
      deployments: {}
      webhookConfigurationOptions: {}
  dashboard:
    readonly: true
    options:
      disabled: false
      configMaps: {}
      deployments: {}
      webhookConfigurationOptions: {}
  result:
    disabled: false
    is_external_db: false
    options: {}
    performance:
      disable-ha: false
      buckets: 1
      replicas: 1
  trigger:
    disabled: false
platforms:
    openshift:
      pipelinesAsCode:
        additionalPACControllers:
          <controllerName>:
            enable: true
            configMapName:
            secretName:
            settings:
        enable: true
        settings:
          application-name: Pipelines as Code CI
          auto-configure-new-github-repo: "false"
          bitbucket-cloud-check-source-ip: "true"
          custom-console-name: ""
          custom-console-url: ""
          custom-console-url-pr-details: ""
          custom-console-url-pr-tasklog: ""
          error-detection-from-container-logs: "false"
          error-detection-max-number-of-lines: "50"
          error-detection-simple-regexp:
            ^(?P<filename>[^:]*):(?P<line>[0-9]+):(?P<column>[0-9]+):([
            ]*)?(?P<error>.*)
          error-log-snippet: "true"
          error-log-snippet-number-of-lines: "3"
          enable-cancel-in-progress-on-pull-requests: "false"
          enable-cancel-in-progress-on-push: "false"
          hub-catalog-name: tekton
          hub-url: https://api.hub.tekton.dev/v1
          require-ok-to-test-sha: "false"
          skip-push-event-for-pr-commits: "true"
          remote-tasks: "true"
          secret-auto-create: "true"
          secret-github-app-token-scoped: "true"
      options:
        disabled: false
        configMaps: {}
        deployments: {}
        webhookConfigurationOptions: {}

Look for the particular section to understand a particular field in the spec.

Target Namespace

This allows user to choose a namespace to install the Tekton Components such as pipelines, triggers.

By default, namespace would be tekton-pipelines for Kubernetes and openshift-pipelines for OpenShift.

Note: Namespace openshift-operators is not allowed in OpenShift as a targetNamespace.

Target Namespace Metadata

targetNamespaceMetadata allows user to add their custom labels and annotations to the target namespace via TektonConfig CR.

Profile

This allows user to choose which all components to install on the cluster. There are 3 profiles available:

all: This profile will install all components (TektonPipeline, TektonTrigger, TektonResult and TektonChain)
basic: This profile will install only TektonPipeline, TektonTrigger, TektonResult and TektonChain component
lite: This profile will install only TektonPipeline component

On Kubernetes, all profile will install TektonDashboard and on OpenShift TektonAddon will be installed.

Config

Config provides fields to configure deployments created by the Operator. This provides following fields:

User can pass the required fields and this would be passed to all Operator components which will get added in all deployments created by Operator.

Example:

config:
  nodeSelector:
    key: value
  tolerations:
    - key: "key1"
      operator: "Equal"
      value: "value1"
      effect: "NoSchedule"
  priorityClassName: system-node-critical

This is an Optional section.

NOTE: If spec.config.priorityClassName is used, then the required priorityClass is expected to be created by the user to get the Tekton resources pods in running state

Pipeline

Pipeline section allows user to customize the Tekton pipeline features. This allow user to customize the values in configmaps.

Refer to properties section in TektonPipeline for available options.

Example:

pipeline:
  disable-affinity-assistant: false
  disable-creds-init: false
  disable-home-env-overwrite: true
  disable-working-directory-overwrite: true
  enable-api-fields: stable
  enable-custom-tasks: false
  metrics.pipelinerun.duration-type: histogram
  metrics.pipelinerun.level: pipelinerun
  metrics.taskrun.duration-type: histogram
  metrics.taskrun.level: taskrun
  traces.enabled: true
  traces.endpoint: "http://jaeger-collector.jaeger.svc.cluster.local:4318/v1/traces"
  traces.credentialsSecret: "" # optional
  require-git-ssh-secret-known-hosts: false
  running-in-environment-with-injected-sidecars: true
  trusted-resources-verification-no-match-policy: ignore
  performance:
    replicas: 1
    disable-ha: false
    buckets: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10

Chain

Chain section allows user to customize the Tekton Chain features. This allows user to customize the values in configmaps

Refer to properties section in TektonChain for available options

Example:

chain:
  disabled: false # - `disabled` : if the value set as `true`, chains feature will be disabled (default: `false`)
  targetNamespace: tekton-pipelines
  generateSigningSecret: true # default value: false
  controllerEnvs:
    - name: MONGO_SERVER_URL # This is the only field supported at the moment which is optional and when added by user, it is added as env to Chains controller
      value: #value               # This can be provided same as env field of container
  artifacts.taskrun.format: in-toto
  artifacts.taskrun.storage: tekton,oci (comma separated values)
  artifacts.taskrun.signer: x509
  artifacts.oci.storage: oci (comma separated values)
  artifacts.oci.format: simplesigning
  artifacts.oci.signer: x509
  artifacts.pipelinerun.format: in-toto
  artifacts.pipelinerun.storage: tekton,oci (comma separated values)
  artifacts.pipelinerun.signer: x509
  storage.gcs.bucket: #value
  storage.oci.repository: #value
  storage.oci.repository.insecure: #value (boolean - true/false)
  storage.docdb.url: #value
  storage.grafeas.projectid: #value
  storage.grafeas.noteid: #value
  storage.grafeas.notehint: #value
  builder.id: #value
  signers.x509.fulcio.enabled: #value (boolean - true/false)
  signers.x509.fulcio.address: #value
  signers.x509.fulcio.issuer: #value
  signers.x509.fulcio.provider: #value
  signers.x509.identity.token.file: #value
  signers.x509.tuf.mirror.url: #value
  signers.kms.kmsref: #value
  signers.kms.kmsref.auth.address: #value
  signers.kms.kmsref.auth.token: #value
  signers.kms.kmsref.auth.oidc.path: #value
  signers.kms.kmsref.auth.oidc.role: #value
  signers.kms.kmsref.auth.spire.sock: #value
  signers.kms.kmsref.auth.spire.audience: #value
  transparency.enabled: #value (boolean - true/false)
  transparency.url: #value

Result

Result section allows user to customize the Tekton Result component, Refer to Result Spec section in TektonResult for available options.

Default Result configuration in TektonConfig looks like following if user doesn’t specified any configuration options

Example:

result:
  disabled: false
  is_external_db: false
  options: {}

User can customize Result configuration with following options

Example:

result:
  disabled: false # - `disabled` : if the value set as `true`, result component will be disabled (default: `false`)
  targetNamespace: tekton-pipelines
  is_external_db: false # By default, this is set to false, TektonOperator will create Tekton Results database. If set to true, an external database will be used, and Tekton Results will retrieve its database credentials from the Kubernetes secret named tekton-results-postgres
  db_host: localhost
  db_port: 5342
  db_sslmode: verify-full
  db_sslrootcert: /etc/tls/db/ca.crt
  db_enable_auto_migration: true
  log_level: debug
  logs_api: true
  logs_type: File
  logs_buffer_size: 90kb
  logs_path: /logs
  auth_disable: true
  logging_pvc_name: tekton-logs
  secret_name: # optional
  gcs_creds_secret_name: <value>
  gcc_creds_secret_key: <value>
  gcs_bucket_name: <value>
  loki_stack_name: #optional
  loki_stack_namespace: #optional
  prometheus_port: 9090
  prometheus_histogram: false

User can configure custom database secret name for internal/external database via Tekton Config CR.

Example:

result:
  db_secret_name: # custom database secret name
  db_secret_user_key: # optional: required if custom database secret user key is not "POSTGRES_USER"
  db_secret_password_key: # optional: required if custom database secret password key is not "POSTGRES_PASSWORD"

Pruner

Pruner provides auto clean up feature for the Tekton pipelinerun and taskrun resources. In the background pruner container runs tkn command.

Example:

pruner:
  disabled: false
  schedule: "0 8 * * *"
  startingDeadlineSeconds: 100 # optional
  resources:
    - taskrun
    - pipelinerun
  keep: 3
  # keep-since: 1440
  # NOTE: you can use either "keep" or "keep-since", not both
  prune-per-resource: true

disabled : if the value set as true, pruner feature will be disabled (default: false)
schedule: how often to run the pruner job. User can understand the schedule syntax here.
startingDeadlineSeconds: Optional deadline in seconds for starting the job if it misses scheduled time for any reason. Missed jobs executions will be counted as failed ones
resources: supported resources for auto prune are taskrun and pipelinerun
keep: maximum number of resources to keep while deleting or removing resources
keep-since: retain the resources younger than the specified value in minutes
prune-per-resource: if the value set as true (default value false), the keep applied to each resource. The resources(pipeline and/or task) taken dynamically from that namespace and applied.
example: in a namespace ns-1 I have two pipeline, named pipeline-1 and pipeline-2, the out come would be: tkn pipelinerun delete --pipeline=my-pipeline-1 --keep=3 --namespace=ns-1, tkn pipelinerun delete --pipeline=my-pipeline-2 --keep=3 --namespace=ns-1. the same way works for task too.
We do not see any benefit by enabling prune-per-resource=true, when you use keep-since. As keep-since is limiting the resources by time(irrespective of resource count), there is no change on the outcome.

Note:

if disabled: false and schedule: with empty value, global pruner job will be disabled. however, if there is a prune schedule (operator.tekton.dev/prune.schedule) annotation present with a value in a namespace. a namespace wide pruner jobs will be created.

Pruner Namespace annotations

operator.tekton.dev/prune.skip - pruner job will be skipped to a namespace, if the value set as true
operator.tekton.dev/prune.schedule - pruner job will be created on a specific schedule
operator.tekton.dev/prune.keep - maximum number of resources will be kept
operator.tekton.dev/prune.keep-since - retain the resources younger than the specified value in minutes
operator.tekton.dev/prune.prune-per-resource - the keep or keep-since applied to each resource
operator.tekton.dev/prune.resources - can be taskrun and/or pipelinerun, both value can be specified with comma separated. example: taskrun,pipelinerun
operator.tekton.dev/prune.strategy - allowed values: either keep or keep-since

Note:

if a global value is not present the following values will be consider as default value
> resources: pipelinerun
> keep: 100

Addon

TektonAddon install some resources along with Tekton Pipelines on the cluster. This provides few PipelineTemplates, ResolverTasks, ResolverStepActions and CommunityResolverTasks.

This section allows to customize installation of those resources through params. You can read more about the supported params here.

Example:

addon:
  params:
    - name: "pipelineTemplates"
      value: "true"
    - name: "resolverTasks"
      value: "true"
    - name: "resolverStepActions"
      value: "true"
    - name: "communityResolverTasks"
      value: "true"

NOTE: TektonAddon is currently available for OpenShift Platform only. Enabling this for Kubernetes platform is in roadmap of Operator.

Hub

Example:

hub:
  params:
    - name: enable-devconsole-integration
      value: "false"

Dashboard

Dashboard provides configuration options for the Tekton Dashboard if the specified profile value includes the Dashboard component. (E.g. all on Kubernetes)

Example:

dashboard:
  readonly: true

readonly: If set to true, install the Dashboard in read-only mode

This is an Optional section.

Resolvers

As part of TektonPipelines, resolvers are installed which are by default enabled. User can disable them through TektonConfig.

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    enable-bundles-resolver: true
    enable-cluster-resolver: true
    enable-git-resolver: true
    enable-hub-resolver: true

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    bundles-resolver-config:
      default-service-account: pipelines
    cluster-resolver-config:
      default-namespace: cluster-resolver-test
    enable-bundles-resolver: true
    enable-cluster-resolver: true
    enable-git-resolver: true
    enable-hub-resolver: true
    git-resolver-config:
      server-url: localhost.com
    hub-resolver-config:
      default-tekton-hub-catalog: tekton
      tekton-hub-api: "https://my-custom-tekton-hub.example.com"
      artifact-hub-api: "https://my-custom-artifact-hub.example.com"

tekton-hub-api => TEKTON_HUB_API
artifact-hub-api => ARTIFACT_HUB_API

OpenShiftPipelinesAsCode

Example:

platforms:
  openshift:
    pipelinesAsCode:
      additionalPACControllers:
        controllername:
          enable: true
          configMapName:
          secretName:
          settings:
      enable: true
      settings:
        application-name: Pipelines as Code CI
        auto-configure-new-github-repo: "false"
        bitbucket-cloud-check-source-ip: "true"
        custom-console-name: ""
        custom-console-url: ""
        custom-console-url-pr-details: ""
        custom-console-url-pr-tasklog: ""
        error-detection-from-container-logs: "false"
        error-detection-max-number-of-lines: "50"
        error-detection-simple-regexp:
          ^(?P<filename>[^:]*):(?P<line>[0-9]+):(?P<column>[0-9]+):([
          ]*)?(?P<error>.*)
        error-log-snippet: "true"
        enable-cancel-in-progress-on-pull-requests: "false"
        enable-cancel-in-progress-on-push: "false"
        hub-catalog-name: tekton
        hub-url: https://api.hub.tekton.dev/v1
        require-ok-to-test-sha: "false"
        remote-tasks: "true"
        secret-auto-create: "true"
        secret-github-app-token-scoped: "true"

Remote Hub Catalogs

Pipelines as Code supports configuring remote hub catalogs to fetch tasks and pipelines. You can configure custom catalogs using the catalog-{INDEX}-* settings pattern.

Each custom catalog requires the following four fields:

Field	Description	Required
`catalog-{INDEX}-id`	Unique identifier for the catalog. Users reference tasks from this catalog using this ID as prefix (e.g., `custom://task-name`)	Yes
`catalog-{INDEX}-name`	Name of the catalog within the hub	Yes
`catalog-{INDEX}-url`	URL endpoint of the hub API	Yes
`catalog-{INDEX}-type`	Type of hub: `artifacthub` (for Artifact Hub) or `tektonhub` (for Tekton Hub)	Yes

Where {INDEX} is a number that can be incremented to add multiple catalogs (e.g., 1, 2, 3).

Example: Configuring a Custom Hub Catalog

platforms:
  openshift:
    pipelinesAsCode:
      enable: true
      settings:
        catalog-1-id: "custom"
        catalog-1-name: "tekton"
        catalog-1-url: "https://api.custom.hub/v1"
        catalog-1-type: "tektonhub"

Example: Configuring Multiple Hub Catalogs

You can configure multiple hub catalogs by incrementing the catalog-{INDEX} number:

platforms:
  openshift:
    pipelinesAsCode:
      enable: true
      settings:
        catalog-1-id: "custom"
        catalog-1-name: "tekton"
        catalog-1-url: "https://api.custom.hub/v1"
        catalog-1-type: "tektonhub"
        catalog-2-id: "artifact"
        catalog-2-name: "tekton-catalog-tasks"
        catalog-2-url: "https://artifacthub.io"
        catalog-2-type: "artifacthub"

Referencing Tasks from Custom Catalogs

Once configured, users can reference tasks from custom catalogs by adding a prefix matching the catalog ID:

pipelinesascode.tekton.dev/task: "custom://git-clone"
pipelinesascode.tekton.dev/task: "artifact://buildah"

Note: Pipelines-as-Code will not try to fallback to the default or another custom hub if the task referenced is not found (the Pull Request will be set as failed).

For more details, see the Pipelines-as-Code Remote Hub Catalogs documentation.

NOTE: OpenShiftPipelinesAsCode is currently available for the OpenShift Platform only.

Event based pruner

Important: This component is disabled by default. To enable the event-based pruner, the existing job-based pruner pruner MUST be disabled.

Basic Configuration

  pruner:
    disabled: true  # Must disable job-based pruner
  tektonpruner:
    disabled: false  # Enable event-based pruner
    global-config:
      enforcedConfigLevel: global  # Options: global, namespace
      ttlSecondsAfterFinished: 3600  # Delete runs older than 1 hour (optional)
      historyLimit: 100              # Keep only 100 runs total (optional)
      successfulHistoryLimit: 50     # Keep only 50 successful runs (optional)
      failedHistoryLimit: 20         # Keep only 20 failed runs (optional)
    options: {}

Configuration Levels

The enforcedConfigLevel determines the configuration hierarchy:

global: Cluster-wide defaults apply to all namespaces (no namespace overrides allowed)
namespace: Allows namespace-level overrides via ConfigMaps in individual namespaces

Pruning Fields

You can specify any combination of these fields. The pruner deletes runs when any one of the specified conditions is met:

ttlSecondsAfterFinished: Time in seconds to retain completed runs before pruning
historyLimit: Maximum number of runs to retain for each status (applies independently to both successful and failed runs)
successfulHistoryLimit: Maximum number of successful runs to retain
failedHistoryLimit: Maximum number of failed runs to retain

Note: If successfulHistoryLimit or failedHistoryLimit is not specified, historyLimit value is used as fallback for that status type.

Namespace-Level Configuration

Configure different default pruning policies for specific namespaces in the global config:

  tektonpruner:
    disabled: false
    global-config:
      enforcedConfigLevel: namespace
      historyLimit: 100  # Global default
      namespaces:
        dev-namespace:
          historyLimit: 50
          ttlSecondsAfterFinished: 1800  # 30 minutes for dev
        prod-namespace:
          successfulHistoryLimit: 200
          failedHistoryLimit: 50
          ttlSecondsAfterFinished: 86400  # 24 hours for prod

Note: For advanced configurations including resource-level selectors and per-namespace overrides via ConfigMaps, refer to the TektonPruner documentation.

Complete Example

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  targetNamespace: tekton-pipelines
  profile: all
  pruner:
    disabled: true  # Disable job-based pruner
  tektonpruner:
    disabled: false
    global-config:
      enforcedConfigLevel: namespace
      historyLimit: 100
      ttlSecondsAfterFinished: 7200  # 2 hours
      namespaces:
        tekton-pipelines:
          historyLimit: 200
          successfulHistoryLimit: 150
          failedHistoryLimit: 50
        dev:
          ttlSecondsAfterFinished: 3600  # 1 hour
          historyLimit: 50
    options:
      disabled: false
      deployments:
        tekton-pruner-controller:
          spec:
            replicas: 1

Configuration Notes:

Both pruners (job-based and event-based) cannot be enabled simultaneously
The event-based pruner responds to resource events in real-time, providing more efficient cleanup
When enforcedConfigLevel is set to namespace, individual namespaces can override these settings using ConfigMaps

Additional fields as `options`

There is a field called options available in all the components.

NOTE: There is a possibility to have two different values for a field.
An example: with a pre-defined field you can set value and the same field may be defined under options as well. In that case value from options will be final.

A sample options field,

options:
  disabled: false
  configMaps:
    config-leader-election: # name of the configMap
      data:
        lease-duration: "90s"
    pipeline-config-logging: # creates new configMap under targetNamespace
      metadata:
        labels:
          my-custom-logger: "true"
        annotations:
          logger-type: "uber-zap"
      data:
        loglevel.controller: "info"
        loglevel.webhook: "info"
        zap-logger-config: |
          {
            "level": "debug",
            "development": false,
            "sampling": {
              "initial": 100,
              "thereafter": 50
            },
            "outputPaths": ["stdout"],
            "errorOutputPaths": ["stderr"],
            "encoding": "json",
            "encoderConfig": {
              "timeKey": "ts",
              "levelKey": "severity",
              "nameKey": "logger",
              "callerKey": "caller",
              "messageKey": "message",
              "stacktraceKey": "stacktrace",
              "lineEnding": "",
              "levelEncoder": "",
              "timeEncoder": "iso8601",
              "durationEncoder": "",
              "callerEncoder": ""
            }
          }          

  deployments:
    tekton-pipelines-controller: # name of the deployment
      metadata:
        labels:
          custom-label: "foo"
        annotations:
          custom-annotation: "foo"
      spec:
        replicas: 2
        template:
          spec:
            containers:
              - name: tekton-pipelines-controller
                env:
                  - name: CONFIG_LOGGING_NAME
                    value: pipeline-config-logging
  statefulSets:
    web: # name of the statefulSets
      metadata:
        labels:
          custom-label: foo
        annotations:
          custom-annotation: foo
      spec:
        replicas: 3
        template:
          spec:
            containers:
              - name: nginx
                env:
                  - name: NGINX_MODE
                    value: production
  horizontalPodAutoscalers:
    tekton-pipelines-webhook: # name of the hpa
      metadata:
        annotations:
        labels:
      spec:
        minReplicas: 2
        maxReplicas: 7
        metrics:
          - resource:
              name: cpu
              target:
                averageUtilization: 85
                type: Utilization
            type: Resource
  webhookConfigurationOptions:
    validation.webhook.pipeline.tekton.dev:
      failurePolicy: Fail
      timeoutSeconds: 20
      sideEffects: None
    webhook.pipeline.tekton.dev:
      failurePolicy: Fail
      timeoutSeconds: 20
      sideEffects: None

disabled - disables the additional options support, if disabled set to true. default: false

ConfigMaps

Supports to update existing configMap also supports to create new configMap.

The following fields are supported in configMap

metadata
- labels - supports add and update
- annotations - supports add and update
data - supports add and update

Deployments

Supports to update the existing deployments. But not supported to create new deployment.

The following fields are supported in deployment

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- replicas - updates deployment replicas count
- template
  - metadata
    - labels - supports add and update
    - annotations - supports add and update
  - spec
    - affinity - replaces the existing Affinity with this, if not empty
    - priorityClassName - replaces the existing PriorityClassName with this, if not empty
    - nodeSelector - replaces the existing NodeSelector with this, if not empty
    - tolerations - replaces the existing tolerations with this, if not empty
    - topologySpreadConstraints - replaces the existing TopologySpreadConstraints with this, if not empty
    - runtimeClassName - adds and updates runtimeClassName
    - volumes - adds and updates volumes
    - initContainers - adds and updates init-containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS
    - containers - adds and updates containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS

StatefulSets

Supports to update the existing StatefulSet. But not supported to create new StatefulSet.

The following fields are supported in StatefulSet

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- replicas - updates statefulSets replicas count
- serviceName - updates service name
- podManagementPolicy - updates pod management policy
- volumeClaimTemplates - updates volume claim templates
- template
  - metadata
    - labels - supports add and update
    - annotations - supports add and update
  - spec
    - affinity - replaces the existing Affinity with this, if not empty
    - priorityClassName - replaces the existing PriorityClassName with this, if not empty
    - nodeSelector - replaces the existing NodeSelector with this, if not empty
    - tolerations - replaces the existing tolerations with this, if not empty
    - topologySpreadConstraints - replaces the existing TopologySpreadConstraints with this, if not empty
    - runtimeClassName - adds and updates runtimeClassName
    - volumes - adds and updates volumes
    - initContainers - adds and updates init-containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS
    - containers - adds and updates containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS

HorizontalPodAutoscalers

Supports to update the existing HorizontalPodAutoscaler(HPA) also supports to create new HPA.

The following fields are supported in HorizontalPodAutoscaler (aka HPA)

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- scaleTargetRef - replaces scaleTargetRef with this, if kind and name are not empty
- minReplicas - updates minimum replicas count
- maxReplicas - updates maximum replicas count
- metrics - replaces the metrics details with this array, if not empty
- behavior - updates behavior data with this, if not empty
  - scaleUp - replaces scaleUp with this, if not empty
  - scaleDown - replaces scaleDown with this, if not empty

webhookConfigurationOptions

the following options are supported for webhookConfigurationOptions

failurePolicy - defines how unrecognized errors and timeout errors from the admission webhook are handled. Allowed values are Ignore or Fail
timeoutSeconds - allows configuring how long the API server should wait for a webhook to respond before treating the call as a failure.
sideEffects - indicates whether the webhook have a side effet. Allowed values are None, NoneOnDryRun, Unknown, or Some

Docs: Getting started with Tekton Dashboard

Mon, 01 Jan 0001 00:00:00 +0000

This tutorial shows you how to

Create a Kubernetes cluster with minikube
Install Tekton Pipelines and Tekton Dashboard
Import some Tekton resources
Create a TaskRun and monitor its logs
Create a PipelineRun and monitor its logs

[!CAUTION] This tutorial describes setting Dashboard up in READ-WRITE mode.

Anyone who can access the Dashboard can use the permissions granted to the service account. Make sure to take additional precautions if your deployment is publicly accessible.

READ-WRITE mode is not a requirement for Dashboard to operate, and can be installed in READ-ONLY mode.

Prerequisites

Install minikube. You only have to complete the step 1, “Installation”.
Install kubectl

Create your Kubernetes cluster

Create a cluster

minikube start --profile tekton-dashboard-tutorial

The process takes a few seconds, you see an output similar to the following, depending on the minikube driver that you are using:

😄  [tekton-dashboard-tutorial] minikube v1.25.2
✨  Using the docker driver based on existing profile
👍  Starting control plane node tekton-dashboard-tutorial in cluster tekton-dashboard-tutorial
🚜  Pulling base image ...
🔥  Creating docker container (CPUs=2, Memory=3886MB) ...
🐳  Preparing Kubernetes v1.23.3 on Docker 20.10.12 ...
    ▪ kubelet.housekeeping-interval=5m
    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...
    ▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "tekton-dashboard-tutorial" cluster and "default" namespace by default

You can check that the cluster was successfully created with kubectl:

kubectl cluster-info

The output confirms that Kubernetes is running:

Kubernetes control plane is running at https://127.0.0.1:39509
CoreDNS is running at
https://127.0.0.1:39509/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

Install Tekton Pipelines

To install the latest version of Tekton Pipelines, use kubectl:

kubectl apply --filename \
https://infra.tekton.dev/tekton-releases/pipeline/latest/release.yaml

Monitor the installation:

kubectl get pods --namespace tekton-pipelines --watch

When all components show Running under the STATUS column the installation is complete.

Hit Ctrl + C to stop monitoring.

Install Tekton Dashboard

To install the latest version of Tekton Dashboard, use kubectl:
```
kubectl apply --filename \
https://infra.tekton.dev/tekton-releases/dashboard/latest/release-full.yaml
```
NOTE: release-full.yaml installs dashboard in READ-WRITE mode.

Monitor the installation:

kubectl get pods --namespace tekton-pipelines --watch

When all components show Running under the STATUS column the installation is complete.

Hit Ctrl + C to stop monitoring.

Access Tekton Dashboard

The Tekton Dashboard is not exposed outside the cluster by default, but we can access it by port-forwarding to the tekton-dashboard Service on port 9097.

kubectl port-forward -n tekton-pipelines service/tekton-dashboard 9097:9097

You can now open the Dashboard in your browser at http://localhost:9097

Grant permissions

The import must be executed using a ServiceAccount with permissions to create the resources being imported.

For this tutorial we will create a ClusterRole granting permission to create a number of Tekton resources, and a RoleBinding configuring this so that the default ServiceAccount in the tekton-dashboard namespace can create resources in the default namespace.

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: tekton-dashboard-tutorial
rules:
  - apiGroups:
      - tekton.dev
    resources:
      - tasks
      - taskruns
      - pipelines
      - pipelineruns
    verbs:
      - get
      - create
      - update
      - patch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: tekton-dashboard-tutorial
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: tekton-dashboard-tutorial
subjects:
  - kind: ServiceAccount
    name: default
    namespace: tekton-dashboard
EOF

Import some Tekton resources using the Tekton Dashboard

We will import two simple Tasks and a Pipeline definition to demonstrate some of the features of the Dashboard.

Navigate to the ‘Import resources’ page in the Dashboard using the link in the main navigation
Fill in the form providing the following information:
- Repository URL: https://github.com/tektoncd/dashboard
- Repository path: docs/tutorial
- Target namespace: default
  - If selecting a different value, ensure the selected ServiceAccount has permission to create resources in this namespace
Leave the default values for the rest of the fields
Click the Import and Apply button

View the progress of the import

The Dashboard creates a PipelineRun to import the specified Tekton resources.

Click on the View status of this run link to track the status of importing the Tekton resources. Alternatively, navigate to the PipelineRuns page and click on the name of the run in the table.

The Tekton resources have been imported when the PipelineRun has completed successfully. You will see the following logs for the ‘import’ step:

pipeline.tekton.dev/hello-goodbye created
task.tekton.dev/hello created
task.tekton.dev/goodbye created

Step completed successfully

Create a TaskRun

Navigate to the TaskRuns page using the link in the main navigation

You will see the TaskRun that was created by the import process. Let’s create another TaskRun using one of the Task definitions we just imported.
Click the Create button and fill in the form as follows:
- Namespace: default
- Task: hello
Leave the default values for the rest of the fields
Click the Create button to create the TaskRun

Once the TaskRun is created you will be taken to the TaskRuns page. View the logs by clicking the TaskRun name in the table.

Wait until the TaskRun has completed successfully and you will see the following logs:

Hello World

Step completed successfully

Create a PipelineRun

Next let’s create a PipelineRun using all of the resources we imported.

Navigate to the PipelineRuns page by clicking the link in the main navigation
Click the Create button

The form is similar to the one we saw for TaskRuns. Both forms are dynamic and provide Param fields based on the selected Task / Pipeline.
Fill in the form with the following information:
- Namespace: default
- Pipeline: hello-goodbye
- Params > hello-greeting: Hello from the tutorial 😀
Leave the default values for the rest of the fields

Note: If you leave the hello-greeting field empty, the default value Hello from a Pipeline defined in the Pipeline will be used.
Click the Create button to create the PipelineRun

Once the PipelineRun is created you will be taken to the PipelineRuns page. View the logs by clicking the PipelineRun name in the table. On the PipelineRun details page you will see two TaskRuns, hello and goodbye, matching the Tasks defined in our Pipeline. Each of these has a step echo which displays a message in the logs.

The logs for the hello Task display the custom message we entered in the create form earlier.

Hello from the tutorial 😀

Step completed successfully

Cleanup

To delete the cluster that you created for this quickstart run:

minikube delete --profile tekton-dashboard-tutorial

The output confirms that your cluster was deleted:

🔥  Deleting "tekton-dashboard-tutorial" in docker ...
🔥  Deleting container "tekton-dashboard-tutorial" ...
🔥  Removing /home/user/.minikube/machines/tekton-dashboard-tutorial ...
💀  Removed all traces of the "tekton-dashboard-tutorial" cluster.

Vault: Getting started with Tekton Dashboard

Mon, 01 Jan 0001 00:00:00 +0000

This tutorial shows you how to

Create a Kubernetes cluster with minikube
Install Tekton Pipelines and Tekton Dashboard
Import some Tekton resources
Create a TaskRun and monitor its logs
Create a PipelineRun and monitor its logs

[!CAUTION] This tutorial describes setting Dashboard up in READ-WRITE mode.

Anyone who can access the Dashboard can use the permissions granted to the service account. Make sure to take additional precautions if your deployment is publicly accessible.

READ-WRITE mode is not a requirement for Dashboard to operate, and can be installed in READ-ONLY mode.

Prerequisites

Install minikube. You only have to complete the step 1, “Installation”.
Install kubectl

Create your Kubernetes cluster

Create a cluster

minikube start --profile tekton-dashboard-tutorial

The process takes a few seconds, you see an output similar to the following, depending on the minikube driver that you are using:

😄  [tekton-dashboard-tutorial] minikube v1.25.2
✨  Using the docker driver based on existing profile
👍  Starting control plane node tekton-dashboard-tutorial in cluster tekton-dashboard-tutorial
🚜  Pulling base image ...
🔥  Creating docker container (CPUs=2, Memory=3886MB) ...
🐳  Preparing Kubernetes v1.23.3 on Docker 20.10.12 ...
    ▪ kubelet.housekeeping-interval=5m
    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...
    ▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "tekton-dashboard-tutorial" cluster and "default" namespace by default

You can check that the cluster was successfully created with kubectl:

kubectl cluster-info

The output confirms that Kubernetes is running:

Kubernetes control plane is running at https://127.0.0.1:39509
CoreDNS is running at
https://127.0.0.1:39509/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

Install Tekton Pipelines

To install the latest version of Tekton Pipelines, use kubectl:

kubectl apply --filename \
https://infra.tekton.dev/tekton-releases/pipeline/latest/release.yaml

Monitor the installation:

kubectl get pods --namespace tekton-pipelines --watch

When all components show Running under the STATUS column the installation is complete.

Hit Ctrl + C to stop monitoring.

Install Tekton Dashboard

To install the latest version of Tekton Dashboard, use kubectl:
```
kubectl apply --filename \
https://infra.tekton.dev/tekton-releases/dashboard/latest/release-full.yaml
```
NOTE: release-full.yaml installs dashboard in READ-WRITE mode.

Monitor the installation:

kubectl get pods --namespace tekton-pipelines --watch

When all components show Running under the STATUS column the installation is complete.

Hit Ctrl + C to stop monitoring.

Access Tekton Dashboard

The Tekton Dashboard is not exposed outside the cluster by default, but we can access it by port-forwarding to the tekton-dashboard Service on port 9097.

kubectl port-forward -n tekton-pipelines service/tekton-dashboard 9097:9097

You can now open the Dashboard in your browser at http://localhost:9097

Grant permissions

The import must be executed using a ServiceAccount with permissions to create the resources being imported.

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: tekton-dashboard-tutorial
rules:
  - apiGroups:
      - tekton.dev
    resources:
      - tasks
      - taskruns
      - pipelines
      - pipelineruns
    verbs:
      - get
      - create
      - update
      - patch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: tekton-dashboard-tutorial
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: tekton-dashboard-tutorial
subjects:
  - kind: ServiceAccount
    name: default
    namespace: tekton-dashboard
EOF

Import some Tekton resources using the Tekton Dashboard

We will import two simple Tasks and a Pipeline definition to demonstrate some of the features of the Dashboard.

Navigate to the ‘Import resources’ page in the Dashboard using the link in the main navigation
Fill in the form providing the following information:
- Repository URL: https://github.com/tektoncd/dashboard
- Repository path: docs/tutorial
- Target namespace: default
  - If selecting a different value, ensure the selected ServiceAccount has permission to create resources in this namespace
Leave the default values for the rest of the fields
Click the Import and Apply button

View the progress of the import

The Dashboard creates a PipelineRun to import the specified Tekton resources.

Click on the View status of this run link to track the status of importing the Tekton resources. Alternatively, navigate to the PipelineRuns page and click on the name of the run in the table.

The Tekton resources have been imported when the PipelineRun has completed successfully. You will see the following logs for the ‘import’ step:

pipeline.tekton.dev/hello-goodbye created
task.tekton.dev/hello created
task.tekton.dev/goodbye created

Step completed successfully

Create a TaskRun

Navigate to the TaskRuns page using the link in the main navigation

You will see the TaskRun that was created by the import process. Let’s create another TaskRun using one of the Task definitions we just imported.
Click the Create button and fill in the form as follows:
- Namespace: default
- Task: hello
Leave the default values for the rest of the fields
Click the Create button to create the TaskRun

Once the TaskRun is created you will be taken to the TaskRuns page. View the logs by clicking the TaskRun name in the table.

Wait until the TaskRun has completed successfully and you will see the following logs:

Hello World

Step completed successfully

Create a PipelineRun

Next let’s create a PipelineRun using all of the resources we imported.

Navigate to the PipelineRuns page by clicking the link in the main navigation
Click the Create button

The form is similar to the one we saw for TaskRuns. Both forms are dynamic and provide Param fields based on the selected Task / Pipeline.
Fill in the form with the following information:
- Namespace: default
- Pipeline: hello-goodbye
- Params > hello-greeting: Hello from the tutorial 😀
Leave the default values for the rest of the fields

Note: If you leave the hello-greeting field empty, the default value Hello from a Pipeline defined in the Pipeline will be used.
Click the Create button to create the PipelineRun

The logs for the hello Task display the custom message we entered in the create form earlier.

Hello from the tutorial 😀

Step completed successfully

Cleanup

To delete the cluster that you created for this quickstart run:

minikube delete --profile tekton-dashboard-tutorial

The output confirms that your cluster was deleted:

🔥  Deleting "tekton-dashboard-tutorial" in docker ...
🔥  Deleting container "tekton-dashboard-tutorial" ...
🔥  Removing /home/user/.minikube/machines/tekton-dashboard-tutorial ...
💀  Removed all traces of the "tekton-dashboard-tutorial" cluster.

Vault: Getting started with Tekton Dashboard

Mon, 01 Jan 0001 00:00:00 +0000

This tutorial shows you how to

Create a Kubernetes cluster with minikube
Install Tekton Pipelines and Tekton Dashboard
Import some Tekton resources
Create a TaskRun and monitor its logs
Create a PipelineRun and monitor its logs

[!CAUTION] This tutorial describes setting Dashboard up in READ-WRITE mode.

Anyone who can access the Dashboard can use the permissions granted to the service account. Make sure to take additional precautions if your deployment is publicly accessible.

READ-WRITE mode is not a requirement for Dashboard to operate, and can be installed in READ-ONLY mode.

Prerequisites

Install minikube. You only have to complete the step 1, “Installation”.
Install kubectl

Create your Kubernetes cluster

Create a cluster

minikube start --profile tekton-dashboard-tutorial

The process takes a few seconds, you see an output similar to the following, depending on the minikube driver that you are using:

😄  [tekton-dashboard-tutorial] minikube v1.25.2
✨  Using the docker driver based on existing profile
👍  Starting control plane node tekton-dashboard-tutorial in cluster tekton-dashboard-tutorial
🚜  Pulling base image ...
🔥  Creating docker container (CPUs=2, Memory=3886MB) ...
🐳  Preparing Kubernetes v1.23.3 on Docker 20.10.12 ...
    ▪ kubelet.housekeeping-interval=5m
    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...
    ▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "tekton-dashboard-tutorial" cluster and "default" namespace by default

You can check that the cluster was successfully created with kubectl:

kubectl cluster-info

The output confirms that Kubernetes is running:

Kubernetes control plane is running at https://127.0.0.1:39509
CoreDNS is running at
https://127.0.0.1:39509/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

Install Tekton Pipelines

To install the latest version of Tekton Pipelines, use kubectl:

kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml

Monitor the installation:

kubectl get pods --namespace tekton-pipelines --watch

When all components show Running under the STATUS column the installation is complete.

Hit Ctrl + C to stop monitoring.

Install Tekton Dashboard

To install the latest version of Tekton Dashboard, use kubectl:
```
kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/dashboard/latest/release-full.yaml
```
NOTE: release-full.yaml installs dashboard in READ-WRITE mode.

Monitor the installation:

kubectl get pods --namespace tekton-pipelines --watch

When all components show Running under the STATUS column the installation is complete.

Hit Ctrl + C to stop monitoring.

Access Tekton Dashboard

The Tekton Dashboard is not exposed outside the cluster by default, but we can access it by port-forwarding to the tekton-dashboard Service on port 9097.

kubectl port-forward -n tekton-pipelines service/tekton-dashboard 9097:9097

You can now open the Dashboard in your browser at http://localhost:9097

Grant permissions

The import must be executed using a ServiceAccount with permissions to create the resources being imported.

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: tekton-dashboard-tutorial
rules:
  - apiGroups:
      - tekton.dev
    resources:
      - tasks
      - taskruns
      - pipelines
      - pipelineruns
    verbs:
      - get
      - create
      - update
      - patch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: tekton-dashboard-tutorial
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: tekton-dashboard-tutorial
subjects:
  - kind: ServiceAccount
    name: default
    namespace: tekton-dashboard
EOF

Import some Tekton resources using the Tekton Dashboard

We will import two simple Tasks and a Pipeline definition to demonstrate some of the features of the Dashboard.

Navigate to the ‘Import resources’ page in the Dashboard using the link in the main navigation
Fill in the form providing the following information:
- Repository URL: https://github.com/tektoncd/dashboard
- Repository path: docs/tutorial
- Target namespace: default
  - If selecting a different value, ensure the selected ServiceAccount has permission to create resources in this namespace
Leave the default values for the rest of the fields
Click the Import and Apply button

View the progress of the import

The Dashboard creates a PipelineRun to import the specified Tekton resources.

Click on the View status of this run link to track the status of importing the Tekton resources. Alternatively, navigate to the PipelineRuns page and click on the name of the run in the table.

The Tekton resources have been imported when the PipelineRun has completed successfully. You will see the following logs for the ‘import’ step:

pipeline.tekton.dev/hello-goodbye created
task.tekton.dev/hello created
task.tekton.dev/goodbye created

Step completed successfully

Create a TaskRun

Navigate to the TaskRuns page using the link in the main navigation

You will see the TaskRun that was created by the import process. Let’s create another TaskRun using one of the Task definitions we just imported.
Click the Create button and fill in the form as follows:
- Namespace: default
- Task: hello
Leave the default values for the rest of the fields
Click the Create button to create the TaskRun

Once the TaskRun is created you will be taken to the TaskRuns page. View the logs by clicking the TaskRun name in the table.

Wait until the TaskRun has completed successfully and you will see the following logs:

Hello World

Step completed successfully

Create a PipelineRun

Next let’s create a PipelineRun using all of the resources we imported.

Navigate to the PipelineRuns page by clicking the link in the main navigation
Click the Create button

The form is similar to the one we saw for TaskRuns. Both forms are dynamic and provide Param fields based on the selected Task / Pipeline.
Fill in the form with the following information:
- Namespace: default
- Pipeline: hello-goodbye
- Params > hello-greeting: Hello from the tutorial 😀
Leave the default values for the rest of the fields

Note: If you leave the hello-greeting field empty, the default value Hello from a Pipeline defined in the Pipeline will be used.
Click the Create button to create the PipelineRun

The logs for the hello Task display the custom message we entered in the create form earlier.

Hello from the tutorial 😀

Step completed successfully

Cleanup

To delete the cluster that you created for this quickstart run:

minikube delete --profile tekton-dashboard-tutorial

The output confirms that your cluster was deleted:

🔥  Deleting "tekton-dashboard-tutorial" in docker ...
🔥  Deleting container "tekton-dashboard-tutorial" ...
🔥  Removing /home/user/.minikube/machines/tekton-dashboard-tutorial ...
💀  Removed all traces of the "tekton-dashboard-tutorial" cluster.

Vault: Getting started with Tekton Dashboard

Mon, 01 Jan 0001 00:00:00 +0000

This tutorial shows you how to

Create a Kubernetes cluster with minikube
Install Tekton Pipelines and Tekton Dashboard
Import some Tekton resources
Create a TaskRun and monitor its logs
Create a PipelineRun and monitor its logs

[!CAUTION] This tutorial describes setting Dashboard up in READ-WRITE mode.

Anyone who can access the Dashboard can use the permissions granted to the service account. Make sure to take additional precautions if your deployment is publicly accessible.

READ-WRITE mode is not a requirement for Dashboard to operate, and can be installed in READ-ONLY mode.

Prerequisites

Install minikube. You only have to complete the step 1, “Installation”.
Install kubectl

Create your Kubernetes cluster

Create a cluster

minikube start --profile tekton-dashboard-tutorial

The process takes a few seconds, you see an output similar to the following, depending on the minikube driver that you are using:

😄  [tekton-dashboard-tutorial] minikube v1.25.2
✨  Using the docker driver based on existing profile
👍  Starting control plane node tekton-dashboard-tutorial in cluster tekton-dashboard-tutorial
🚜  Pulling base image ...
🔥  Creating docker container (CPUs=2, Memory=3886MB) ...
🐳  Preparing Kubernetes v1.23.3 on Docker 20.10.12 ...
    ▪ kubelet.housekeeping-interval=5m
    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...
    ▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "tekton-dashboard-tutorial" cluster and "default" namespace by default

You can check that the cluster was successfully created with kubectl:

kubectl cluster-info

The output confirms that Kubernetes is running:

Kubernetes control plane is running at https://127.0.0.1:39509
CoreDNS is running at
https://127.0.0.1:39509/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

Install Tekton Pipelines

To install the latest version of Tekton Pipelines, use kubectl:

kubectl apply --filename \
https://infra.tekton.dev/tekton-releases/pipeline/latest/release.yaml

Monitor the installation:

kubectl get pods --namespace tekton-pipelines --watch

When all components show Running under the STATUS column the installation is complete.

Hit Ctrl + C to stop monitoring.

Install Tekton Dashboard

To install the latest version of Tekton Dashboard, use kubectl:
```
kubectl apply --filename \
https://infra.tekton.dev/tekton-releases/dashboard/latest/release-full.yaml
```
NOTE: release-full.yaml installs dashboard in READ-WRITE mode.

Monitor the installation:

kubectl get pods --namespace tekton-pipelines --watch

When all components show Running under the STATUS column the installation is complete.

Hit Ctrl + C to stop monitoring.

Access Tekton Dashboard

The Tekton Dashboard is not exposed outside the cluster by default, but we can access it by port-forwarding to the tekton-dashboard Service on port 9097.

kubectl port-forward -n tekton-pipelines service/tekton-dashboard 9097:9097

You can now open the Dashboard in your browser at http://localhost:9097

Grant permissions

The import must be executed using a ServiceAccount with permissions to create the resources being imported.

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: tekton-dashboard-tutorial
rules:
  - apiGroups:
      - tekton.dev
    resources:
      - tasks
      - taskruns
      - pipelines
      - pipelineruns
    verbs:
      - get
      - create
      - update
      - patch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: tekton-dashboard-tutorial
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: tekton-dashboard-tutorial
subjects:
  - kind: ServiceAccount
    name: default
    namespace: tekton-dashboard
EOF

Import some Tekton resources using the Tekton Dashboard

We will import two simple Tasks and a Pipeline definition to demonstrate some of the features of the Dashboard.

Navigate to the ‘Import resources’ page in the Dashboard using the link in the main navigation
Fill in the form providing the following information:
- Repository URL: https://github.com/tektoncd/dashboard
- Repository path: docs/tutorial
- Target namespace: default
  - If selecting a different value, ensure the selected ServiceAccount has permission to create resources in this namespace
Leave the default values for the rest of the fields
Click the Import and Apply button

View the progress of the import

The Dashboard creates a PipelineRun to import the specified Tekton resources.

Click on the View status of this run link to track the status of importing the Tekton resources. Alternatively, navigate to the PipelineRuns page and click on the name of the run in the table.

The Tekton resources have been imported when the PipelineRun has completed successfully. You will see the following logs for the ‘import’ step:

pipeline.tekton.dev/hello-goodbye created
task.tekton.dev/hello created
task.tekton.dev/goodbye created

Step completed successfully

Create a TaskRun

Navigate to the TaskRuns page using the link in the main navigation

You will see the TaskRun that was created by the import process. Let’s create another TaskRun using one of the Task definitions we just imported.
Click the Create button and fill in the form as follows:
- Namespace: default
- Task: hello
Leave the default values for the rest of the fields
Click the Create button to create the TaskRun

Once the TaskRun is created you will be taken to the TaskRuns page. View the logs by clicking the TaskRun name in the table.

Wait until the TaskRun has completed successfully and you will see the following logs:

Hello World

Step completed successfully

Create a PipelineRun

Next let’s create a PipelineRun using all of the resources we imported.

Navigate to the PipelineRuns page by clicking the link in the main navigation
Click the Create button

The form is similar to the one we saw for TaskRuns. Both forms are dynamic and provide Param fields based on the selected Task / Pipeline.
Fill in the form with the following information:
- Namespace: default
- Pipeline: hello-goodbye
- Params > hello-greeting: Hello from the tutorial 😀
Leave the default values for the rest of the fields

Note: If you leave the hello-greeting field empty, the default value Hello from a Pipeline defined in the Pipeline will be used.
Click the Create button to create the PipelineRun

The logs for the hello Task display the custom message we entered in the create form earlier.

Hello from the tutorial 😀

Step completed successfully

Cleanup

To delete the cluster that you created for this quickstart run:

minikube delete --profile tekton-dashboard-tutorial

The output confirms that your cluster was deleted:

🔥  Deleting "tekton-dashboard-tutorial" in docker ...
🔥  Deleting container "tekton-dashboard-tutorial" ...
🔥  Removing /home/user/.minikube/machines/tekton-dashboard-tutorial ...
💀  Removed all traces of the "tekton-dashboard-tutorial" cluster.

Vault: Getting started with Tekton Dashboard

Mon, 01 Jan 0001 00:00:00 +0000

This tutorial shows you how to

Create a Kubernetes cluster with minikube
Install Tekton Pipelines and Tekton Dashboard
Import some Tekton resources
Create a TaskRun and monitor its logs
Create a PipelineRun and monitor its logs

[!CAUTION] This tutorial describes setting Dashboard up in READ-WRITE mode.

Anyone who can access the Dashboard can use the permissions granted to the service account. Make sure to take additional precautions if your deployment is publicly accessible.

READ-WRITE mode is not a requirement for Dashboard to operate, and can be installed in READ-ONLY mode.

Prerequisites

Install minikube. You only have to complete the step 1, “Installation”.
Install kubectl

Create your Kubernetes cluster

Create a cluster

minikube start --profile tekton-dashboard-tutorial

The process takes a few seconds, you see an output similar to the following, depending on the minikube driver that you are using:

😄  [tekton-dashboard-tutorial] minikube v1.25.2
✨  Using the docker driver based on existing profile
👍  Starting control plane node tekton-dashboard-tutorial in cluster tekton-dashboard-tutorial
🚜  Pulling base image ...
🔥  Creating docker container (CPUs=2, Memory=3886MB) ...
🐳  Preparing Kubernetes v1.23.3 on Docker 20.10.12 ...
    ▪ kubelet.housekeeping-interval=5m
    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...
    ▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "tekton-dashboard-tutorial" cluster and "default" namespace by default

You can check that the cluster was successfully created with kubectl:

kubectl cluster-info

The output confirms that Kubernetes is running:

Kubernetes control plane is running at https://127.0.0.1:39509
CoreDNS is running at
https://127.0.0.1:39509/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

Install Tekton Pipelines

To install the latest version of Tekton Pipelines, use kubectl:

kubectl apply --filename \
https://infra.tekton.dev/tekton-releases/pipeline/latest/release.yaml

Monitor the installation:

kubectl get pods --namespace tekton-pipelines --watch

When all components show Running under the STATUS column the installation is complete.

Hit Ctrl + C to stop monitoring.

Install Tekton Dashboard

To install the latest version of Tekton Dashboard, use kubectl:
```
kubectl apply --filename \
https://infra.tekton.dev/tekton-releases/dashboard/latest/release-full.yaml
```
NOTE: release-full.yaml installs dashboard in READ-WRITE mode.

Monitor the installation:

kubectl get pods --namespace tekton-pipelines --watch

When all components show Running under the STATUS column the installation is complete.

Hit Ctrl + C to stop monitoring.

Access Tekton Dashboard

The Tekton Dashboard is not exposed outside the cluster by default, but we can access it by port-forwarding to the tekton-dashboard Service on port 9097.

kubectl port-forward -n tekton-pipelines service/tekton-dashboard 9097:9097

You can now open the Dashboard in your browser at http://localhost:9097

Grant permissions

The import must be executed using a ServiceAccount with permissions to create the resources being imported.

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: tekton-dashboard-tutorial
rules:
  - apiGroups:
      - tekton.dev
    resources:
      - tasks
      - taskruns
      - pipelines
      - pipelineruns
    verbs:
      - get
      - create
      - update
      - patch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: tekton-dashboard-tutorial
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: tekton-dashboard-tutorial
subjects:
  - kind: ServiceAccount
    name: default
    namespace: tekton-dashboard
EOF

Import some Tekton resources using the Tekton Dashboard

We will import two simple Tasks and a Pipeline definition to demonstrate some of the features of the Dashboard.

Navigate to the ‘Import resources’ page in the Dashboard using the link in the main navigation
Fill in the form providing the following information:
- Repository URL: https://github.com/tektoncd/dashboard
- Repository path: docs/tutorial
- Target namespace: default
  - If selecting a different value, ensure the selected ServiceAccount has permission to create resources in this namespace
Leave the default values for the rest of the fields
Click the Import and Apply button

View the progress of the import

The Dashboard creates a PipelineRun to import the specified Tekton resources.

Click on the View status of this run link to track the status of importing the Tekton resources. Alternatively, navigate to the PipelineRuns page and click on the name of the run in the table.

The Tekton resources have been imported when the PipelineRun has completed successfully. You will see the following logs for the ‘import’ step:

pipeline.tekton.dev/hello-goodbye created
task.tekton.dev/hello created
task.tekton.dev/goodbye created

Step completed successfully

Create a TaskRun

Navigate to the TaskRuns page using the link in the main navigation

You will see the TaskRun that was created by the import process. Let’s create another TaskRun using one of the Task definitions we just imported.
Click the Create button and fill in the form as follows:
- Namespace: default
- Task: hello
Leave the default values for the rest of the fields
Click the Create button to create the TaskRun

Once the TaskRun is created you will be taken to the TaskRuns page. View the logs by clicking the TaskRun name in the table.

Wait until the TaskRun has completed successfully and you will see the following logs:

Hello World

Step completed successfully

Create a PipelineRun

Next let’s create a PipelineRun using all of the resources we imported.

Navigate to the PipelineRuns page by clicking the link in the main navigation
Click the Create button

The form is similar to the one we saw for TaskRuns. Both forms are dynamic and provide Param fields based on the selected Task / Pipeline.
Fill in the form with the following information:
- Namespace: default
- Pipeline: hello-goodbye
- Params > hello-greeting: Hello from the tutorial 😀
Leave the default values for the rest of the fields

Note: If you leave the hello-greeting field empty, the default value Hello from a Pipeline defined in the Pipeline will be used.
Click the Create button to create the PipelineRun

The logs for the hello Task display the custom message we entered in the create form earlier.

Hello from the tutorial 😀

Step completed successfully

Cleanup

To delete the cluster that you created for this quickstart run:

minikube delete --profile tekton-dashboard-tutorial

The output confirms that your cluster was deleted:

🔥  Deleting "tekton-dashboard-tutorial" in docker ...
🔥  Deleting container "tekton-dashboard-tutorial" ...
🔥  Removing /home/user/.minikube/machines/tekton-dashboard-tutorial ...
💀  Removed all traces of the "tekton-dashboard-tutorial" cluster.

Docs: Build and push an image with Tekton

Mon, 01 Jan 0001 00:00:00 +0000

This page includes content about running Tekton with specific platforms and cloud providers. The accuracy and freshness of this vendor documentation varies by vendor.

If you want to contribute with platform-specific documentation, follow the vendor contributions guidelines.

This guide shows you how to:

Create a Task to clone source code from a git repository.
Create a second Task to use the cloned code to build a Docker image and push it to a registry.

If you are already familiar with Tekton and just want to see the example, you can skip to the full code samples.

Prerequisites

To follow this How-to you must have a Kubernetes cluster up and running and kubectl properly configured to issue commands to your cluster.
Install Tekton Pipelines:
```
kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml
```
See the Pipelines installation documentation for other installation options and vendor specific instructions.
Install the Tekton CLI, tkn, on your machine.

If this is your first time using Tekton Pipelines, we recommend that you complete the Getting Started tutorials before proceeding with this guide.

Clone the repository

Create a new Pipeline, pipeline.yaml, that uses the git clone Task to clone the source code from a git repository:

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: clone-build-push
spec:
  description: | 
    This pipeline clones a git repo, builds a Docker image with Kaniko and
    pushes it to a registry
  params:
  - name: repo-url
    type: string
  workspaces:
  - name: shared-data
  tasks:
  - name: fetch-source
    taskRef:
      name: git-clone
    workspaces:
    - name: output
      workspace: shared-data
    params:
    - name: url
      value: $(params.repo-url)

Then create the corresponding pipelinerun.yaml file:

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  generateName: clone-build-push-run-
spec:
  pipelineRef:
    name: clone-build-push
  podTemplate:
    securityContext:
      fsGroup: 65532
  workspaces:
  - name: shared-data
    volumeClaimTemplate:
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 1Gi
  params:
  - name: repo-url
    value: https://github.com/google/docsy-example.git

For this how-to we are using a public repository as an example. You can also use git clone with private repositories, using SSH authentication.

Build the container image with Kaniko

To build the image use the Kaniko Task from the community hub.

Add the image reference to the params section in pipeline.yaml:
```
params: 
- name: image-reference
  type: string
```
This parameter is used to add the tag corresponding the container registry where you are going to push the image.
Create the new build-push Task in the same pipeline.yaml file:
```
tasks:
...
  - name: build-push
    runAfter: ["fetch-source"]
    taskRef:
      name: kaniko
    workspaces:
    - name: source
      workspace: shared-data
    params:
    - name: IMAGE
      value: $(params.image-reference)
```
This new Task refers to kaniko, which is going to be installed from the community hub. A Task has its own set of workspaces and params passed down from the parameters and Workspaces defined at Pipeline level. In this case, the Workspace source and the value of IMAGE. Check the kaniko Task documentation to see all the available options.
Instantiate the build-push Task. Add the value of image-reference to the params section in pipelinerun.yaml:
```
params:
- name: image-reference
  value: container.registry.com/sublocation/my_app:version
```
Replace container.registry.com/sublocation/my_app:version with the actual tag for your registry. You can set up a local registry for testing purposes.

Check the full code samples to see how all the pieces fit together.

Container registry authentication

In most cases, to push the image to a container registry you must provide authentication credentials first.

Set up authentication with the Docker credential helper and generate the Docker configuration file, $HOME/.docker/config.json, for your registry. This step is different depending on your registry.
Check your cloud provider documentation to complete this step.
Create a Kubernetes Secret, docker-credentials.yaml with your credentials:
```
apiVersion: v1
kind: Secret
metadata:
  name: docker-credentials
data:
  config.json: efuJAmF1...
```
The value of config.json is the base64-encoded ~/.docker/config.json file. You can get this data with the following command:
```
cat ~/.docker/config.json | base64 -w0
```
Update pipeline.yaml and add a Workspace to mount the credentials directory:

At the Pipeline level:
```
workspaces:
- name: docker-credentials
```
And under the build-push Task:
```
workspaces:
- name: dockerconfig
  workspace: docker-credentials
```
Instantiate the new docker-credentials Workspace in your pipelinerun.yaml file by adding a new entry under workspaces:
```
- name: docker-credentials
  secret:
    secretName: docker-credentials
```

GKE Workload Identity

If you are running your Pipelines on Google Kubernetes Engine (GKE), create a cluster with Workload Identity enabled or enable Workload Identity on an existing cluster. This allows you to to run your pipeline and push images to Artifact Registry without authentication credentials. If you are using Workload Identity, skip step 2 when you run your pipeline.

Set up an Artifact Registry repository:

Enable the Artifact Registry API:

gcloud services enable artifactregistry.googleapis.com

Create a Docker repository to push the image to:
```
gcloud artifacts repositories create <repository-name> \
  --repository-format=docker \
  --location=us-central1 --description="Docker repository"
```
Replace:
- <repository-name> with the name of your repository.
- <location> with the name of your preferred location. For example, us-central1.

Configure the GKE cluster to allow the Pipeline to push images to Artifact Registry:

Create a Kubernetes Service Account:
```
kubectl create serviceaccount <sa-name>
```
Where <sa-name> is the name of the service account. For example, tekton-sa.
Create a Google Service Account with the same name:
```
gcloud iam service-accounts create <sa-name>
```

Grant the Google Service Account permissions to push to the Artifact Registry container repository:

gcloud artifacts repositories add-iam-policy-binding <ar-repository> \
  --location <location> \
  --member=serviceAccount:build-robot@<project_id>.iam.gserviceaccount.com \
  --role=roles/artifactregistry.reader \
  --role=roles/artifactregistry.writer

Where

<ar-repository> is the name of the repository.
<location> is the repository repository location.
<project_id> is the project id.

Set up the Workload Identity mappings on the Kubernetes cluster:

kubectl annotate serviceaccount \
<sa-name> \
iam.gke.io/gcp-service-account=build-robot@<project_id>.iam.gserviceaccount.com

Set up Workload Identity mappings for the Google Service Account:

gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:<project_id>.svc.id.goog[default/<sa-name>]" \
  build-robot@<project_id>.iam.gserviceaccount.com

This creates two service accounts, an IAM service account and a Kubernetes service account, and “links” them. Workload Identity allows workloads in your GKE cluster to impersonate IAM service accounts to access Google Cloud services.

Use Docker authentication

If you prefer to use Docker authentication to push your image to Artifact Registry, there are two options:

In both cases your credentials are saved to a Docker configuration file in your user home directory: $HOME/.docker/config.json. Use this file to follow the “General Authentication” instructions.

See the complete files in the full code samples section.

Run your Pipeline

You are ready to install the Tasks and run the pipeline.

Install the git-clone and kaniko Tasks:

tkn hub install task git-clone
tkn hub install task kaniko

Apply the Secret with your Docker credentials.
```
kubectl apply -f docker-credentials.yaml
```
Apply the Pipeline:
```
kubectl apply -f pipeline.yaml
```

Create the PipelineRun:

kubectl create -f pipelinerun.yaml

This creates a PipelineRun with a unique name each time:

pipelinerun.tekton.dev/clone-build-push-run-4kgjr created

Use the PipelineRun name from the output of the previous step to monitor the Pipeline execution:

tkn pipelinerun logs  clone-build-push-run-4kgjr -f

After a few seconds, the output confirms that the image was built and pushed successfully:

[fetch-source : clone] + '[' false '=' true ]
[fetch-source : clone] + '[' false '=' true ]
[fetch-source : clone] + '[' false '=' true ]
[fetch-source : clone] + CHECKOUT_DIR=/workspace/output/
[fetch-source : clone] + '[' true '=' true ]
[fetch-source : clone] + cleandir
[fetch-source : clone] + '[' -d /workspace/output/ ]
[fetch-source : clone] + rm -rf '/workspace/output//*'
[fetch-source : clone] + rm -rf '/workspace/output//.[!.]*'
[fetch-source : clone] + rm -rf '/workspace/output//..?*'
[fetch-source : clone] + test -z 
[fetch-source : clone] + test -z 
[fetch-source : clone] + test -z 
[fetch-source : clone] + /ko-app/git-init '-url=https://github.com/google/docsy-example.git' '-revision=' '-refspec=' '-path=/workspace/output/' '-sslVerify=true' '-submodules=true' '-depth=1' '-sparseCheckoutDirectories='
[fetch-source : clone] {"level":"info","ts":1654637310.4419358,"caller":"git/git.go:170","msg":"Successfully cloned https://github.com/google/docsy-example.git @ 1c7f7e300c90cd690ca5be66b43fe58713bb21c9 (grafted, HEAD) in path /workspace/output/"}
[fetch-source : clone] {"level":"info","ts":1654637320.384655,"caller":"git/git.go:208","msg":"Successfully initialized and updated submodules in path /workspace/output/"}
[fetch-source : clone] + cd /workspace/output/
[fetch-source : clone] + git rev-parse HEAD
[fetch-source : clone] + RESULT_SHA=1c7f7e300c90cd690ca5be66b43fe58713bb21c9
[fetch-source : clone] + EXIT_CODE=0
[fetch-source : clone] + '[' 0 '!=' 0 ]
[fetch-source : clone] + printf '%s' 1c7f7e300c90cd690ca5be66b43fe58713bb21c9
[fetch-source : clone] + printf '%s' https://github.com/google/docsy-example.git

[build-push : build-and-push] WARN
[build-push : build-and-push] User provided docker configuration exists at /kaniko/.docker/config.json 
[build-push : build-and-push] INFO Retrieving image manifest klakegg/hugo:ext-alpine 
[build-push : build-and-push] INFO Retrieving image klakegg/hugo:ext-alpine from registry index.docker.io 
[build-push : build-and-push] INFO Built cross stage deps: map[]                
[build-push : build-and-push] INFO Retrieving image manifest klakegg/hugo:ext-alpine 
[build-push : build-and-push] INFO Returning cached image manifest              
[build-push : build-and-push] INFO Executing 0 build triggers                   
[build-push : build-and-push] INFO Unpacking rootfs as cmd RUN apk add git requires it. 
[build-push : build-and-push] INFO RUN apk add git                              
[build-push : build-and-push] INFO Taking snapshot of full filesystem...        
[build-push : build-and-push] INFO cmd: /bin/sh                                 
[build-push : build-and-push] INFO args: [-c apk add git]                       
[build-push : build-and-push] INFO Running: [/bin/sh -c apk add git]            
[build-push : build-and-push] fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/main/x86_64/APKINDEX.tar.gz
[build-push : build-and-push] fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/community/x86_64/APKINDEX.tar.gz
[build-push : build-and-push] OK: 76 MiB in 41 packages
[build-push : build-and-push] INFO[0012] Taking snapshot of full filesystem...        
[build-push : build-and-push] INFO[0013] Pushing image to us-east1-docker.pkg.dev/tekton-tests/tektonstuff/docsy:v1 
[build-push : build-and-push] INFO[0029] Pushed image to 1 destinations               

[build-push : write-url] us-east1-docker.pkg.dev/my-tekton-tests/tekton-samples/docsy:v1

Full code samples

The Pipeline:

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: clone-build-push
spec:
  description: |
    This pipeline clones a git repo, builds a Docker image with Kaniko and
    pushes it to a registry    
  params:
  - name: repo-url
    type: string
  - name: image-reference
    type: string
  workspaces:
  - name: shared-data
  - name: docker-credentials
  tasks:
  - name: fetch-source
    taskRef:
      name: git-clone
    workspaces:
    - name: output
      workspace: shared-data
    params:
    - name: url
      value: $(params.repo-url)
  - name: build-push
    runAfter: ["fetch-source"]
    taskRef:
      name: kaniko
    workspaces:
    - name: source
      workspace: shared-data
    - name: dockerconfig
      workspace: docker-credentials
    params:
    - name: IMAGE
      value: $(params.image-reference)

The PipelineRun:

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  generateName: clone-build-push-run-
spec:
  pipelineRef:
    name: clone-build-push
  podTemplate:
    securityContext:
      fsGroup: 65532
  workspaces:
  - name: shared-data
    volumeClaimTemplate:
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 1Gi
  - name: docker-credentials
    secret:
      secretName: docker-credentials
  params:
  - name: repo-url
    value: https://github.com/google/docsy-example.git
  - name: image-reference
    value: container.registry.com/sublocation/my_app:version

The Docker credentials Kubernetes Secret:

apiVersion: v1
kind: Secret
metadata:
  name: docker-credentials
data:
  config.json: efuJAmF1...

Use your credentials as the value of the data field. Check the registry authentication section for more information.

Docs: Concept model

Mon, 01 Jan 0001 00:00:00 +0000

Steps, Tasks, and Pipelines

A step is an operation in a CI/CD workflow, such as running some unit tests for a Python web app, or the compilation of a Java program. Tekton performs each step with a container image you provide. For example, you may use the official Go image to compile a Go program in the same manner as you would on your local workstation (go build).

A task is a collection of steps in order. Tekton runs a task in the form of a Kubernetes pod, where each step becomes a running container in the pod. This design allows you to set up a shared environment for a number of related steps; for example, you may mount a Kubernetes volume in a task, which will be accessible inside each step of the task.

A pipeline is a collection of tasks in order. Tekton collects all the tasks, connects them in a directed acyclic graph (DAG), and executes the graph in sequence. In other words, it creates a number of Kubernetes pods and ensures that each pod completes running successfully as desired. Tekton grants developers full control of the process: one may set up a fan-in/fan-out scenario of task completion, ask Tekton to retry automatically should a flaky test exists, or specify a condition that a task must meet before proceeding.

Tasks and pipelines are specified as custom resources in a Kubernetes cluster.

TaskRuns and PipelineRuns

A pipelineRun, as its name implies, is a specific execution of a pipeline. For example, you may ask Tekton to run your CI/CD workflow twice a day, and each execution will become a pipelineRun resource trackable in your Kubernetes cluster. You can view the status of your CI/CD workflow, including the specifics of each task execution with pipelineRuns.

Similarly, a taskRun is a specific execution of a task. TaskRuns are also available when you choose to run a task outside a pipeline, with which you may view the specifics of each step execution in a task.

TaskRuns and pipelineRuns connect resources with tasks and pipelines. A run must include the actual addresses of resources, such as the URLs of repositories, its task or pipeline needs. This design allows developers to reuse tasks and pipelines for different inputs and outputs.

You may create taskRuns or pipelineRuns manually, which triggers Tekton to run a task or a pipeline immediately. Alternately, one may ask a Tekton component, such as Tekton Triggers, to create a run automatically on demand; for example, you may want to run a pipeline every time a new pull request is checked into your git repository.

TaskRuns and pipelineRuns are specified as custom resources in a Kubernetes cluster.

How Tekton works

Loosely speaking, at its core, Tekton Pipelines functions by wrapping each of your steps. More specifically, Tekton Pipelines injects an entrypoint binary in step containers, which executes the command you specify when the system is ready.

Tekton Pipelines tracks the state of your pipeline using Kubernetes Annotations. These annotations are projected inside each step container in the form of files with the Kubernetes Downward API. The entrypoint binary watches the projected files closely, and will only start the provided command if a specific annotation appears as files. For example, when you ask Tekton to run two steps consecutively in a task, the entrypoint binary injected into the second step container will wait idly until the annotations report that the first step container has successfully completed.

In addition, Tekton Pipelines schedules some containers to run automatically before and after your step containers, so as to support specific built-in features, such as the retrieval of input resources and the uploading of outputs to blob storage solutions. You can track their running statuses as well via taskRuns and pipelineRuns. The system also performs a number of other operations to set up the environment before running the step containers; for more information, see Tasks and Pipelines.

What’s next

Learn more about Tekton Pipelines in Tasks and Pipelines.

Docs: Formatting conventions

Mon, 01 Jan 0001 00:00:00 +0000

Tekton documentation uses Markdown to format the content. See the CommonMark tutorial to learn the basics.

Markdown formatting conventions:

Lists
- Capitalize the first word for each item.
- Don’t put a period at the end of each item in lists containing only nouns or single-word items.
- Use sentence punctuation in any other case.
Code Format
- Use code formatting when referencing API objects, commands, files and directories.
- Use angle brackets for placeholders such as variables. For example:
```
kubectl apply -f <pipeline-file>
```
Markdown files
- Hard-wrap the file lines so they are not longer than 80 characters.
- Use reference-style links if the URL is too long. There’s no specific URL length, use your best judgment to keep markdown files readable.

Embed code samples

You can import code from external files. To do this, use the readfile shortcode with the code and lang options. For example, the following code embeds the file samples/task.yaml:

{{< readfile file="samples/task.yaml" code="true" lang="yaml" >}}

This is rendered as:

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: hello
spec:
  steps:
    - name: echo
      image: alpine
      script: |
        #!/bin/sh
        echo "Hello World"

You can also embed code samples in tabs using the tabpane shortcode. For example, the following code embeds samples/pipeline1.yaml and samples/pipeline2.yaml in different tabs:

{{< tabs >}}
{{< tab "v1beta1" >}}
{{< readfile file="samples/pipeline1.yaml" code="true" lang="yaml" >}}
{{< /tab >}}

{{< tab "v1" >}}
{{< readfile file="samples/pipeline2.yaml" code="true" lang="yaml" >}}
{{< /tab >}}
{{< /tabs >}}

Rendered as:

v1beta1
v1

apiVersion: tekton.dev/v1beta1
kind: TaskRun
spec:
  taskRef:
    name: example-task
    bundle: python:3-alpine

apiVersion: tekton.dev/v1
kind: TaskRun
spec:
  taskRef:
    resolver: bundles
    params:
    - name: bundle
      value: python:3-alpine
    - name: name
      value: taskName
    - name: kind
      value: Task

Warning

The path parameter don’t support relative paths to parent directories. For example, path="../sample.yaml" does not work.

Docs: Getting Started with Pipelines

Mon, 01 Jan 0001 00:00:00 +0000

This tutorial shows you how to:

Create two Tasks.
Create a Pipeline containing your Tasks.
Use PipelineRun to instantiate and run the Pipeline containing your Tasks.

This guide uses a local cluster with minikube.

Prerequisites

Complete the Getting started with Tasks tutorial. Do not clean up your resources, skip the last section.
Install tkn, the Tekton CLI.

Create and run a second Task

You already have a “Hello World!” Task. To create a second “Goodbye!” Task:

Create a new file named goodbye-world.yaml and add the following content:

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: goodbye
spec:
  params:
  - name: username
    type: string
  steps:
    - name: goodbye
      image: ubuntu
      script: |
        #!/bin/bash
        echo "Goodbye $(params.username)!"

This Task takes one parameter, username. Whenever this Task is used a value for that parameter must be passed to the Task.

Apply the Task file:

kubectl apply --filename goodbye-world.yaml

When a Task is part of a Pipeline, Tekton creates a TaskRun object for every task in the Pipeline.

Create and run a Pipeline

A Pipeline defines an ordered series of Tasks arranged in a specific execution order as part of the CI/CD workflow.

In this section you are going to create your first Pipeline, that will include both the “Hello World!” and “Goodbye!” Tasks.

Create a new file named hello-goodbye-pipeline.yaml and add the following content:

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: hello-goodbye
spec:
  params:
  - name: username
    type: string
  tasks:
    - name: hello
      taskRef:
        name: hello
    - name: goodbye
      runAfter:
        - hello
      taskRef:
        name: goodbye
      params:
      - name: username
        value: $(params.username)

The Pipeline defines the parameter username, which is then passed to the goodbye Task.

Apply the Pipeline configuration to your cluster:

kubectl apply --filename hello-goodbye-pipeline.yaml

A PipelineRun, represented in the API as an object of kind PipelineRun, sets the value for the parameters and executes a Pipeline. To create PipelineRun, create a new file named hello-goodbye-pipeline-run.yaml with the following:
```
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: hello-goodbye-run
spec:
  pipelineRef:
    name: hello-goodbye
  params:
  - name: username
    value: "Tekton"
```
This sets the actual value for the username parameter: "Tekton".
Start the Pipeline by applying the PipelineRun configuration to your cluster:
```
kubectl apply --filename hello-goodbye-pipeline-run.yaml
```
You see the following output:
```
pipelinerun.tekton.dev/hello-goodbye-run created
```
Tekton now starts running the Pipeline.

To see the logs of the PipelineRun, use the following command:

tkn pipelinerun logs hello-goodbye-run -f -n default

The output shows both Tasks completed successfully:

[hello : echo] Hello World!

[goodbye : goodbye] Goodbye Tekton!

Cleanup

To learn about Tekton Triggers, skip this section and proceed to the next tutorial.

To delete the cluster that you created for this guide run:

minikube delete

The output confirms that the cluster was deleted:

🔥  Deleting "minikube" in qemu2 ...
💀  Removed all traces of the "minikube" cluster.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Installing Tekton Dashboard

This guide explains how to install Tekton Dashboard. It covers the following topics:

Installing Tekton Dashboard

Before you begin

Choose the version of Tekton Dashboard you want to install. You have the following options:

Official - install this unless you have a specific reason to go for a different release.
Nightly - may contain bugs, install at your own risk.
[HEAD] - this is the bleeding edge. It contains unreleased code that may result in unpredictable behavior. To get started, see the development guide instead of this page.

Pre-requisites

In order to install the Tekton Dashboard, please make sure the following requirements are met:

You must have a Kubernetes cluster running version 1.31.0 or later. Tekton Pipelines or other projects may require a newer version. The Dashboard may work on older Kubernetes versions but this is untested and not officially supported.

If you don’t already have a cluster, you can create one for testing with kind. Install kind and create a cluster by running kind create cluster. This will create a cluster running locally, with RBAC enabled and your user granted the cluster-admin role.
Tekton Pipelines must be installed in the cluster. See Installing Tekton Pipelines.
Optionally, install Tekton Triggers. See Installing Tekton Triggers.

Supported Tekton Pipelines and Tekton Triggers versions

Each Tekton Dashboard release is tested against specific Tekton Pipelines and Tekton Triggers versions. See the Tekton Dashboard release notes for details of the supported versions.

Installing Tekton Dashboard on Kubernetes

To install Tekton Dashboard on a Kubernetes cluster:

Run the following command to install Tekton Dashboard:
```
kubectl apply --filename https://infra.tekton.dev/tekton-releases/dashboard/latest/release.yaml
```
This will install the Dashboard in read-only mode by default.

Previous versions are available at previous/$VERSION_NUMBER/*.yaml, e.g. https://infra.tekton.dev/tekton-releases/dashboard/previous/v0.32.0/release.yaml

To install in read/write mode, use release-full.yaml.

v0.31.0 and earlier used a different naming scheme for the release manifests:

Mode Current v0.31.0 and earlier

read-only release.yaml tekton-dashboard-release-readonly.yaml

read/write release-full.yaml tekton-dashboard-release.yaml
Monitor the installation using the following command until all components show a Running status:
```
kubectl get pods --namespace tekton-pipelines --watch
```
Note: Hit CTRL+C to stop monitoring.

Mode	Current	v0.31.0 and earlier
read-only	release.yaml	tekton-dashboard-release-readonly.yaml
read/write	release-full.yaml	tekton-dashboard-release.yaml

Congratulations! You have successfully installed Tekton Dashboard on your Kubernetes cluster.

Installing with the installer script

v0.8.0 and later releases provide an installer script to simplify deploying the Tekton Dashboard with custom options.

You can refer to the dev docs for more info on how to use the installer.

For example:

to install the latest release in read/write mode:

curl -sL https://raw.githubusercontent.com/tektoncd/dashboard/main/scripts/release-installer | \
  bash -s -- install latest --read-write

to install with access to a subset of namespaces instead of full cluster access:
```
curl -sL https://raw.githubusercontent.com/tektoncd/dashboard/main/scripts/release-installer | \
  bash -s -- install latest --read-write --tenant-namespaces tenant-namespace1,tenant-namespace2
```
This will add the --namespaces arg to the Dashboard deployment and create RoleBindings in each of the specified namespaces with appropriate roles granted to the Dashboard ServiceAccount.

to install with support for loading logs from an external source:

curl -sL https://raw.githubusercontent.com/tektoncd/dashboard/main/scripts/release-installer | \
  bash -s -- install latest --read-write --external-logs <logs-provider-url>

See Tekton Dashboard walk-through - Logs persistence for details

Accessing the Dashboard

By default, the Dashboard is not exposed outside the cluster.

There are several solutions described below for accessing the Dashboard UI depending on your setup.

Using kubectl proxy

The Dashboard can be accessed through its ClusterIP Service by running kubectl proxy.

Assuming tekton-pipelines is the install namespace for the Dashboard, run the following command:

kubectl proxy

Browse http://localhost:8001/api/v1/namespaces/tekton-pipelines/services/tekton-dashboard:http/proxy/ to access your Dashboard.

Using kubectl port-forward

An alternative way to access the Dashboard is using kubectl port-forward.

Assuming tekton-pipelines is the install namespace for the Dashboard, run the following command:

kubectl --namespace tekton-pipelines port-forward svc/tekton-dashboard 9097:9097

Browse http://localhost:9097 to access your Dashboard.

Using an Ingress rule

A more advanced solution is to expose the Dashboard through an Ingress rule.

This way the Dashboard can be accessed as a regular website without requiring kubectl.

Assuming you have an ingress controller up and running in your cluster, and that tekton-pipelines is the install namespace for the Dashboard, run the following command to create the Ingress resource:

# replace DASHBOARD_URL with the hostname you want for your dashboard
# the hostname should be setup to point to your ingress controller
DASHBOARD_URL=dashboard.domain.tld
kubectl apply -n tekton-pipelines -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tekton-dashboard
  namespace: tekton-pipelines
spec:
  rules:
  - host: $DASHBOARD_URL
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: tekton-dashboard
            port:
              number: 9097
EOF

You can now access the Dashboard UI at http(s)://dashboard.domain.tld in your browser (assuming the host configured in the ingress is dashboard.domain.tld)

Notes:

The exact Ingress resource definition may vary a little depending on the ingress controller installed in the cluster. Some specific annotations may be required for the ingress controller to process the Ingress resource correctly
If you don’t have access to a domain you can use the freely available nip.io service

An example using the NGINX ingress controller to expose the Dashboard on a specific path instead of at the root of the domain:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tekton-dashboard
  namespace: tekton-pipelines
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - host: domain.tld
    http:
      paths:
      - path: /tekton(/|$)(.*)
        backend:
          service:
            name: tekton-dashboard
            port:
              number: 9097

You can then access the Dashboard UI at http(s)://domain.tld/tekton/

Access control

The Dashboard does not provide its own authentication or authorization, however it will pass on any authentication headers provided to it by a proxy deployed in front of the Dashboard. These are then handled by the Kubernetes API server allowing for full access control via Kubernetes RBAC. In case of forbidden access the Dashboard will display corresponding error notifications.

See the walk-throughs for an example of enabling authentication using oauth2-proxy.

By default the Dashboard accesses resources and performs actions in the cluster using the permissions granted to its own ServiceAccount (i.e. the tekton-dashboard ServiceAccount in the tekton-pipelines namespace). If you wish to have the Dashboard perform actions on behalf of the authenticated user or some other ServiceAccount this can be achieved via user impersonation. This is known to work with a number of popular solutions including oauth2-proxy, Keycloak, OpenUnison, Traefik, Istio’s EnvoyFilter, and more.

Typically when configuring impersonation you would have the proxy forward its ServiceAccount token in the Authorization header, and details of the user and groups in the Impersonate-User and Impersonate-Group headers respectively. See the docs of your chosen solution for details.

When using a reverse proxy, with impersonation headers or the user’s account, you should remove the Dashboard’s privileges to better maintain a “least privileged” approach. This will make it less likely that the Dashboard’s ServiceAccount will be abused:

kubectl delete clusterrolebinding -l rbac.dashboard.tekton.dev/subject=tekton-dashboard
kubectl delete rolebinding -l rbac.dashboard.tekton.dev/subject=tekton-dashboard -n tekton-pipelines

If you’re using one of these proxies to provide authentication but still want to use the Dashboard’s ServiceAccount to access the Kubernetes APIs you may need to modify the proxy config to prevent it from sending the Authorization header on upstream requests to the Dashboard. Some examples of relevant config:

oauth2-proxy: add the --pass-authorization-header=false command line argument or its equivalent to your config https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/overview#command-line-options
Istio EnvoyFilter: the external authentication service should return a custom header x-envoy-auth-headers-to-remove: Authorization https://www.envoyproxy.io/docs/envoy/latest/api-v3/service/auth/v3/external_auth.proto
Traefik: removeHeader: true https://doc.traefik.io/traefik/v2.0/middlewares/basicauth/#removeheader

Uninstalling the Dashboard on Kubernetes

The Dashboard can be uninstalled by running the following command:

kubectl delete --filename https://infra.tekton.dev/tekton-releases/dashboard/latest/release.yaml

The above command assumes that the current latest version was installed, refer to Installing Tekton Dashboard on Kubernetes to find the correct --filename argument if another version was installed.

Next steps

To get started with Tekton Dashboard, see the tutorial.

To add more functionality to your Tekton Dashboard, see the Tekton Dashboard extensions

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License. Code samples are licensed under the Apache 2.0 License.

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Installing Tekton Dashboard

This guide explains how to install Tekton Dashboard. It covers the following topics:

Installing Tekton Dashboard

Before you begin

Choose the version of Tekton Dashboard you want to install. You have the following options:

Official - install this unless you have a specific reason to go for a different release.
Nightly - may contain bugs, install at your own risk.
[HEAD] - this is the bleeding edge. It contains unreleased code that may result in unpredictable behavior. To get started, see the development guide instead of this page.

Pre-requisites

In order to install the Tekton Dashboard, please make sure the following requirements are met:

You must have a Kubernetes cluster running version 1.31.0 or later. Tekton Pipelines or other projects may require a newer version. The Dashboard may work on older Kubernetes versions but this is untested and not officially supported.

If you don’t already have a cluster, you can create one for testing with kind. Install kind and create a cluster by running kind create cluster. This will create a cluster running locally, with RBAC enabled and your user granted the cluster-admin role.
Tekton Pipelines must be installed in the cluster. See Installing Tekton Pipelines.
Optionally, install Tekton Triggers. See Installing Tekton Triggers.

Supported Tekton Pipelines and Tekton Triggers versions

Each Tekton Dashboard release is tested against specific Tekton Pipelines and Tekton Triggers versions. See the Tekton Dashboard release notes for details of the supported versions.

Installing Tekton Dashboard on Kubernetes

To install Tekton Dashboard on a Kubernetes cluster:

Run the following command to install Tekton Dashboard:
```
kubectl apply --filename https://infra.tekton.dev/tekton-releases/dashboard/latest/release.yaml
```
This will install the Dashboard in read-only mode by default.

Previous versions are available at previous/$VERSION_NUMBER/*.yaml, e.g. https://infra.tekton.dev/tekton-releases/dashboard/previous/v0.32.0/release.yaml

To install in read/write mode, use release-full.yaml.

v0.31.0 and earlier used a different naming scheme for the release manifests:

Mode Current v0.31.0 and earlier

read-only release.yaml tekton-dashboard-release-readonly.yaml

read/write release-full.yaml tekton-dashboard-release.yaml
Monitor the installation using the following command until all components show a Running status:
```
kubectl get pods --namespace tekton-pipelines --watch
```
Note: Hit CTRL+C to stop monitoring.

Mode	Current	v0.31.0 and earlier
read-only	release.yaml	tekton-dashboard-release-readonly.yaml
read/write	release-full.yaml	tekton-dashboard-release.yaml

Congratulations! You have successfully installed Tekton Dashboard on your Kubernetes cluster.

Installing with the installer script

v0.8.0 and later releases provide an installer script to simplify deploying the Tekton Dashboard with custom options.

You can refer to the dev docs for more info on how to use the installer.

For example:

to install the latest release in read/write mode:

curl -sL https://raw.githubusercontent.com/tektoncd/dashboard/main/scripts/release-installer | \
  bash -s -- install latest --read-write

to install with access to a subset of namespaces instead of full cluster access:
```
curl -sL https://raw.githubusercontent.com/tektoncd/dashboard/main/scripts/release-installer | \
  bash -s -- install latest --read-write --tenant-namespaces tenant-namespace1,tenant-namespace2
```
This will add the --namespaces arg to the Dashboard deployment and create RoleBindings in each of the specified namespaces with appropriate roles granted to the Dashboard ServiceAccount.

to install with support for loading logs from an external source:

curl -sL https://raw.githubusercontent.com/tektoncd/dashboard/main/scripts/release-installer | \
  bash -s -- install latest --read-write --external-logs <logs-provider-url>

See Tekton Dashboard walk-through - Logs persistence for details

Accessing the Dashboard

By default, the Dashboard is not exposed outside the cluster.

There are several solutions described below for accessing the Dashboard UI depending on your setup.

Using kubectl proxy

The Dashboard can be accessed through its ClusterIP Service by running kubectl proxy.

Assuming tekton-pipelines is the install namespace for the Dashboard, run the following command:

kubectl proxy

Browse http://localhost:8001/api/v1/namespaces/tekton-pipelines/services/tekton-dashboard:http/proxy/ to access your Dashboard.

Using kubectl port-forward

An alternative way to access the Dashboard is using kubectl port-forward.

Assuming tekton-pipelines is the install namespace for the Dashboard, run the following command:

kubectl --namespace tekton-pipelines port-forward svc/tekton-dashboard 9097:9097

Browse http://localhost:9097 to access your Dashboard.

Using an Ingress rule

A more advanced solution is to expose the Dashboard through an Ingress rule.

This way the Dashboard can be accessed as a regular website without requiring kubectl.

# replace DASHBOARD_URL with the hostname you want for your dashboard
# the hostname should be setup to point to your ingress controller
DASHBOARD_URL=dashboard.domain.tld
kubectl apply -n tekton-pipelines -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tekton-dashboard
  namespace: tekton-pipelines
spec:
  rules:
  - host: $DASHBOARD_URL
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: tekton-dashboard
            port:
              number: 9097
EOF

You can now access the Dashboard UI at http(s)://dashboard.domain.tld in your browser (assuming the host configured in the ingress is dashboard.domain.tld)

Notes:

The exact Ingress resource definition may vary a little depending on the ingress controller installed in the cluster. Some specific annotations may be required for the ingress controller to process the Ingress resource correctly
If you don’t have access to a domain you can use the freely available nip.io service

An example using the NGINX ingress controller to expose the Dashboard on a specific path instead of at the root of the domain:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tekton-dashboard
  namespace: tekton-pipelines
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - host: domain.tld
    http:
      paths:
      - path: /tekton(/|$)(.*)
        backend:
          service:
            name: tekton-dashboard
            port:
              number: 9097

You can then access the Dashboard UI at http(s)://domain.tld/tekton/

Access control

See the walk-throughs for an example of enabling authentication using oauth2-proxy.

kubectl delete clusterrolebinding -l rbac.dashboard.tekton.dev/subject=tekton-dashboard
kubectl delete rolebinding -l rbac.dashboard.tekton.dev/subject=tekton-dashboard -n tekton-pipelines

oauth2-proxy: add the --pass-authorization-header=false command line argument or its equivalent to your config https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/overview#command-line-options
Istio EnvoyFilter: the external authentication service should return a custom header x-envoy-auth-headers-to-remove: Authorization https://www.envoyproxy.io/docs/envoy/latest/api-v3/service/auth/v3/external_auth.proto
Traefik: removeHeader: true https://doc.traefik.io/traefik/v2.0/middlewares/basicauth/#removeheader

Uninstalling the Dashboard on Kubernetes

The Dashboard can be uninstalled by running the following command:

kubectl delete --filename https://infra.tekton.dev/tekton-releases/dashboard/latest/release.yaml

The above command assumes that the current latest version was installed, refer to Installing Tekton Dashboard on Kubernetes to find the correct --filename argument if another version was installed.

Next steps

To get started with Tekton Dashboard, see the tutorial.

To add more functionality to your Tekton Dashboard, see the Tekton Dashboard extensions

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License. Code samples are licensed under the Apache 2.0 License.

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Installing Tekton Dashboard

This guide explains how to install Tekton Dashboard. It covers the following topics:

Before you begin

Choose the version of Tekton Dashboard you want to install. You have the following options:

Official - install this unless you have a specific reason to go for a different release.
Nightly - may contain bugs, install at your own risk.
[HEAD] - this is the bleeding edge. It contains unreleased code that may result in unpredictable behavior. To get started, see the development guide instead of this page.

Pre-requisites

In order to install the Tekton Dashboard, please make sure the following requirements are met:

You must have a Kubernetes cluster running version 1.28.0 or later. Tekton Pipelines or other projects may require a newer version. The Dashboard may work on older Kubernetes versions but this is untested and not officially supported.

If you don’t already have a cluster, you can create one for testing with kind. Install kind and create a cluster by running kind create cluster. This will create a cluster running locally, with RBAC enabled and your user granted the cluster-admin role.
Tekton Pipelines must be installed in the cluster. See Installing Tekton Pipelines.
Optionally, install Tekton Triggers. See Installing Tekton Triggers.

Supported Tekton Pipelines and Tekton Triggers versions

Each Tekton Dashboard release is tested against specific Tekton Pipelines and Tekton Triggers versions. See the Tekton Dashboard release notes for details of the supported versions.

Installing Tekton Dashboard on Kubernetes

To install Tekton Dashboard on a Kubernetes cluster:

Run the following command to install Tekton Dashboard:
```
kubectl apply --filename https://storage.googleapis.com/tekton-releases/dashboard/latest/release.yaml
```
This will install the Dashboard in read-only mode by default.

Previous versions are available at previous/$VERSION_NUMBER/*.yaml, e.g. https://storage.googleapis.com/tekton-releases/dashboard/previous/v0.32.0/release.yaml

To install in read/write mode, use release-full.yaml.

v0.31.0 and earlier used a different naming scheme for the release manifests:

Mode Current v0.31.0 and earlier

read-only release.yaml tekton-dashboard-release-readonly.yaml

read/write release-full.yaml tekton-dashboard-release.yaml
Monitor the installation using the following command until all components show a Running status:
```
kubectl get pods --namespace tekton-pipelines --watch
```
Note: Hit CTRL+C to stop monitoring.

Mode	Current	v0.31.0 and earlier
read-only	release.yaml	tekton-dashboard-release-readonly.yaml
read/write	release-full.yaml	tekton-dashboard-release.yaml

Congratulations! You have successfully installed Tekton Dashboard on your Kubernetes cluster.

Installing with the installer script

v0.8.0 and later releases provide an installer script to simplify deploying the Tekton Dashboard with custom options.

You can refer to the dev docs for more info on how to use the installer.

For example:

to install the latest release in read/write mode:

curl -sL https://raw.githubusercontent.com/tektoncd/dashboard/main/scripts/release-installer | \
  bash -s -- install latest --read-write

to install with access to a subset of namespaces instead of full cluster access:
```
curl -sL https://raw.githubusercontent.com/tektoncd/dashboard/main/scripts/release-installer | \
  bash -s -- install latest --read-write --tenant-namespaces tenant-namespace1,tenant-namespace2
```
This will add the --namespaces arg to the Dashboard deployment and create RoleBindings in each of the specified namespaces with appropriate roles granted to the Dashboard ServiceAccount.

to install with support for loading logs from an external source:

curl -sL https://raw.githubusercontent.com/tektoncd/dashboard/main/scripts/release-installer | \
  bash -s -- install latest --read-write --external-logs <logs-provider-url>

See Tekton Dashboard walk-through - Logs persistence for details

Accessing the Dashboard

By default, the Dashboard is not exposed outside the cluster.

There are several solutions described below for accessing the Dashboard UI depending on your setup.

Using kubectl proxy

The Dashboard can be accessed through its ClusterIP Service by running kubectl proxy.

Assuming tekton-pipelines is the install namespace for the Dashboard, run the following command:

kubectl proxy

Browse http://localhost:8001/api/v1/namespaces/tekton-pipelines/services/tekton-dashboard:http/proxy/ to access your Dashboard.

Using kubectl port-forward

An alternative way to access the Dashboard is using kubectl port-forward.

Assuming tekton-pipelines is the install namespace for the Dashboard, run the following command:

kubectl --namespace tekton-pipelines port-forward svc/tekton-dashboard 9097:9097

Browse http://localhost:9097 to access your Dashboard.

Using an Ingress rule

A more advanced solution is to expose the Dashboard through an Ingress rule.

This way the Dashboard can be accessed as a regular website without requiring kubectl.

# replace DASHBOARD_URL with the hostname you want for your dashboard
# the hostname should be setup to point to your ingress controller
DASHBOARD_URL=dashboard.domain.tld
kubectl apply -n tekton-pipelines -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tekton-dashboard
  namespace: tekton-pipelines
spec:
  rules:
  - host: $DASHBOARD_URL
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: tekton-dashboard
            port:
              number: 9097
EOF

You can now access the Dashboard UI at http(s)://dashboard.domain.tld in your browser (assuming the host configured in the ingress is dashboard.domain.tld)

Notes:

The exact Ingress resource definition may vary a little depending on the ingress controller installed in the cluster. Some specific annotations may be required for the ingress controller to process the Ingress resource correctly
If you don’t have access to a domain you can use the freely available nip.io service

An example using the NGINX ingress controller to expose the Dashboard on a specific path instead of at the root of the domain:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tekton-dashboard
  namespace: tekton-pipelines
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - host: domain.tld
    http:
      paths:
      - path: /tekton(/|$)(.*)
        backend:
          service:
            name: tekton-dashboard
            port:
              number: 9097

You can then access the Dashboard UI at http(s)://domain.tld/tekton/

Access control

See the walk-throughs for an example of enabling authentication using oauth2-proxy.

kubectl delete clusterrolebinding -l rbac.dashboard.tekton.dev/subject=tekton-dashboard
kubectl delete rolebinding -l rbac.dashboard.tekton.dev/subject=tekton-dashboard -n tekton-pipelines

oauth2-proxy: add the --pass-authorization-header=false command line argument or its equivalent to your config https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/overview#command-line-options
Istio EnvoyFilter: the external authentication service should return a custom header x-envoy-auth-headers-to-remove: Authorization https://www.envoyproxy.io/docs/envoy/latest/api-v3/service/auth/v3/external_auth.proto
Traefik: removeHeader: true https://doc.traefik.io/traefik/v2.0/middlewares/basicauth/#removeheader

Uninstalling the Dashboard on Kubernetes

The Dashboard can be uninstalled by running the following command:

kubectl delete --filename https://storage.googleapis.com/tekton-releases/dashboard/latest/release.yaml

The above command assumes that the current latest version was installed, refer to Installing Tekton Dashboard on Kubernetes to find the correct --filename argument if another version was installed.

Next steps

To get started with Tekton Dashboard, see the tutorial.

To add more functionality to your Tekton Dashboard, see the Tekton Dashboard extensions

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License. Code samples are licensed under the Apache 2.0 License.

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Installing Tekton Dashboard

This guide explains how to install Tekton Dashboard. It covers the following topics:

Installing Tekton Dashboard

Before you begin

Choose the version of Tekton Dashboard you want to install. You have the following options:

Official - install this unless you have a specific reason to go for a different release.
Nightly - may contain bugs, install at your own risk.
[HEAD] - this is the bleeding edge. It contains unreleased code that may result in unpredictable behavior. To get started, see the development guide instead of this page.

Pre-requisites

In order to install the Tekton Dashboard, please make sure the following requirements are met:

You must have a Kubernetes cluster running version 1.28.0 or later. Tekton Pipelines or other projects may require a newer version. The Dashboard may work on older Kubernetes versions but this is untested and not officially supported.

If you don’t already have a cluster, you can create one for testing with kind. Install kind and create a cluster by running kind create cluster. This will create a cluster running locally, with RBAC enabled and your user granted the cluster-admin role.
Tekton Pipelines must be installed in the cluster. See Installing Tekton Pipelines.
Optionally, install Tekton Triggers. See Installing Tekton Triggers.

Supported Tekton Pipelines and Tekton Triggers versions

Each Tekton Dashboard release is tested against specific Tekton Pipelines and Tekton Triggers versions. See the Tekton Dashboard release notes for details of the supported versions.

Installing Tekton Dashboard on Kubernetes

To install Tekton Dashboard on a Kubernetes cluster:

Run the following command to install Tekton Dashboard:
```
kubectl apply --filename https://infra.tekton.dev/tekton-releases/dashboard/latest/release.yaml
```
This will install the Dashboard in read-only mode by default.

Previous versions are available at previous/$VERSION_NUMBER/*.yaml, e.g. https://infra.tekton.dev/tekton-releases/dashboard/previous/v0.32.0/release.yaml

To install in read/write mode, use release-full.yaml.

v0.31.0 and earlier used a different naming scheme for the release manifests:

Mode Current v0.31.0 and earlier

read-only release.yaml tekton-dashboard-release-readonly.yaml

read/write release-full.yaml tekton-dashboard-release.yaml
Monitor the installation using the following command until all components show a Running status:
```
kubectl get pods --namespace tekton-pipelines --watch
```
Note: Hit CTRL+C to stop monitoring.

Mode	Current	v0.31.0 and earlier
read-only	release.yaml	tekton-dashboard-release-readonly.yaml
read/write	release-full.yaml	tekton-dashboard-release.yaml

Congratulations! You have successfully installed Tekton Dashboard on your Kubernetes cluster.

Installing with the installer script

v0.8.0 and later releases provide an installer script to simplify deploying the Tekton Dashboard with custom options.

You can refer to the dev docs for more info on how to use the installer.

For example:

to install the latest release in read/write mode:

curl -sL https://raw.githubusercontent.com/tektoncd/dashboard/main/scripts/release-installer | \
  bash -s -- install latest --read-write

to install with access to a subset of namespaces instead of full cluster access:
```
curl -sL https://raw.githubusercontent.com/tektoncd/dashboard/main/scripts/release-installer | \
  bash -s -- install latest --read-write --tenant-namespaces tenant-namespace1,tenant-namespace2
```
This will add the --namespaces arg to the Dashboard deployment and create RoleBindings in each of the specified namespaces with appropriate roles granted to the Dashboard ServiceAccount.

to install with support for loading logs from an external source:

curl -sL https://raw.githubusercontent.com/tektoncd/dashboard/main/scripts/release-installer | \
  bash -s -- install latest --read-write --external-logs <logs-provider-url>

See Tekton Dashboard walk-through - Logs persistence for details

Accessing the Dashboard

By default, the Dashboard is not exposed outside the cluster.

There are several solutions described below for accessing the Dashboard UI depending on your setup.

Using kubectl proxy

The Dashboard can be accessed through its ClusterIP Service by running kubectl proxy.

Assuming tekton-pipelines is the install namespace for the Dashboard, run the following command:

kubectl proxy

Browse http://localhost:8001/api/v1/namespaces/tekton-pipelines/services/tekton-dashboard:http/proxy/ to access your Dashboard.

Using kubectl port-forward

An alternative way to access the Dashboard is using kubectl port-forward.

Assuming tekton-pipelines is the install namespace for the Dashboard, run the following command:

kubectl --namespace tekton-pipelines port-forward svc/tekton-dashboard 9097:9097

Browse http://localhost:9097 to access your Dashboard.

Using an Ingress rule

A more advanced solution is to expose the Dashboard through an Ingress rule.

This way the Dashboard can be accessed as a regular website without requiring kubectl.

# replace DASHBOARD_URL with the hostname you want for your dashboard
# the hostname should be setup to point to your ingress controller
DASHBOARD_URL=dashboard.domain.tld
kubectl apply -n tekton-pipelines -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tekton-dashboard
  namespace: tekton-pipelines
spec:
  rules:
  - host: $DASHBOARD_URL
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: tekton-dashboard
            port:
              number: 9097
EOF

You can now access the Dashboard UI at http(s)://dashboard.domain.tld in your browser (assuming the host configured in the ingress is dashboard.domain.tld)

Notes:

The exact Ingress resource definition may vary a little depending on the ingress controller installed in the cluster. Some specific annotations may be required for the ingress controller to process the Ingress resource correctly
If you don’t have access to a domain you can use the freely available nip.io service

An example using the NGINX ingress controller to expose the Dashboard on a specific path instead of at the root of the domain:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tekton-dashboard
  namespace: tekton-pipelines
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - host: domain.tld
    http:
      paths:
      - path: /tekton(/|$)(.*)
        backend:
          service:
            name: tekton-dashboard
            port:
              number: 9097

You can then access the Dashboard UI at http(s)://domain.tld/tekton/

Access control

See the walk-throughs for an example of enabling authentication using oauth2-proxy.

kubectl delete clusterrolebinding -l rbac.dashboard.tekton.dev/subject=tekton-dashboard
kubectl delete rolebinding -l rbac.dashboard.tekton.dev/subject=tekton-dashboard -n tekton-pipelines

oauth2-proxy: add the --pass-authorization-header=false command line argument or its equivalent to your config https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/overview#command-line-options
Istio EnvoyFilter: the external authentication service should return a custom header x-envoy-auth-headers-to-remove: Authorization https://www.envoyproxy.io/docs/envoy/latest/api-v3/service/auth/v3/external_auth.proto
Traefik: removeHeader: true https://doc.traefik.io/traefik/v2.0/middlewares/basicauth/#removeheader

Uninstalling the Dashboard on Kubernetes

The Dashboard can be uninstalled by running the following command:

kubectl delete --filename https://infra.tekton.dev/tekton-releases/dashboard/latest/release.yaml

The above command assumes that the current latest version was installed, refer to Installing Tekton Dashboard on Kubernetes to find the correct --filename argument if another version was installed.

Next steps

To get started with Tekton Dashboard, see the tutorial.

To add more functionality to your Tekton Dashboard, see the Tekton Dashboard extensions

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License. Code samples are licensed under the Apache 2.0 License.

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Installing Tekton Dashboard

This guide explains how to install Tekton Dashboard. It covers the following topics:

Installing Tekton Dashboard

Before you begin

Choose the version of Tekton Dashboard you want to install. You have the following options:

Official - install this unless you have a specific reason to go for a different release.
Nightly - may contain bugs, install at your own risk.
[HEAD] - this is the bleeding edge. It contains unreleased code that may result in unpredictable behavior. To get started, see the development guide instead of this page.

Pre-requisites

In order to install the Tekton Dashboard, please make sure the following requirements are met:

You must have a Kubernetes cluster running version 1.28.0 or later. Tekton Pipelines or other projects may require a newer version. The Dashboard may work on older Kubernetes versions but this is untested and not officially supported.

If you don’t already have a cluster, you can create one for testing with kind. Install kind and create a cluster by running kind create cluster. This will create a cluster running locally, with RBAC enabled and your user granted the cluster-admin role.
Tekton Pipelines must be installed in the cluster. See Installing Tekton Pipelines.
Optionally, install Tekton Triggers. See Installing Tekton Triggers.

Supported Tekton Pipelines and Tekton Triggers versions

Each Tekton Dashboard release is tested against specific Tekton Pipelines and Tekton Triggers versions. See the Tekton Dashboard release notes for details of the supported versions.

Installing Tekton Dashboard on Kubernetes

To install Tekton Dashboard on a Kubernetes cluster:

Run the following command to install Tekton Dashboard:
```
kubectl apply --filename https://infra.tekton.dev/tekton-releases/dashboard/latest/release.yaml
```
This will install the Dashboard in read-only mode by default.

Previous versions are available at previous/$VERSION_NUMBER/*.yaml, e.g. https://infra.tekton.dev/tekton-releases/dashboard/previous/v0.32.0/release.yaml

To install in read/write mode, use release-full.yaml.

v0.31.0 and earlier used a different naming scheme for the release manifests:

Mode Current v0.31.0 and earlier

read-only release.yaml tekton-dashboard-release-readonly.yaml

read/write release-full.yaml tekton-dashboard-release.yaml
Monitor the installation using the following command until all components show a Running status:
```
kubectl get pods --namespace tekton-pipelines --watch
```
Note: Hit CTRL+C to stop monitoring.

Mode	Current	v0.31.0 and earlier
read-only	release.yaml	tekton-dashboard-release-readonly.yaml
read/write	release-full.yaml	tekton-dashboard-release.yaml

Congratulations! You have successfully installed Tekton Dashboard on your Kubernetes cluster.

Installing with the installer script

v0.8.0 and later releases provide an installer script to simplify deploying the Tekton Dashboard with custom options.

You can refer to the dev docs for more info on how to use the installer.

For example:

to install the latest release in read/write mode:

curl -sL https://raw.githubusercontent.com/tektoncd/dashboard/main/scripts/release-installer | \
  bash -s -- install latest --read-write

to install with access to a subset of namespaces instead of full cluster access:
```
curl -sL https://raw.githubusercontent.com/tektoncd/dashboard/main/scripts/release-installer | \
  bash -s -- install latest --read-write --tenant-namespaces tenant-namespace1,tenant-namespace2
```
This will add the --namespaces arg to the Dashboard deployment and create RoleBindings in each of the specified namespaces with appropriate roles granted to the Dashboard ServiceAccount.

to install with support for loading logs from an external source:

curl -sL https://raw.githubusercontent.com/tektoncd/dashboard/main/scripts/release-installer | \
  bash -s -- install latest --read-write --external-logs <logs-provider-url>

See Tekton Dashboard walk-through - Logs persistence for details

Accessing the Dashboard

By default, the Dashboard is not exposed outside the cluster.

There are several solutions described below for accessing the Dashboard UI depending on your setup.

Using kubectl proxy

The Dashboard can be accessed through its ClusterIP Service by running kubectl proxy.

Assuming tekton-pipelines is the install namespace for the Dashboard, run the following command:

kubectl proxy

Browse http://localhost:8001/api/v1/namespaces/tekton-pipelines/services/tekton-dashboard:http/proxy/ to access your Dashboard.

Using kubectl port-forward

An alternative way to access the Dashboard is using kubectl port-forward.

Assuming tekton-pipelines is the install namespace for the Dashboard, run the following command:

kubectl --namespace tekton-pipelines port-forward svc/tekton-dashboard 9097:9097

Browse http://localhost:9097 to access your Dashboard.

Using an Ingress rule

A more advanced solution is to expose the Dashboard through an Ingress rule.

This way the Dashboard can be accessed as a regular website without requiring kubectl.

# replace DASHBOARD_URL with the hostname you want for your dashboard
# the hostname should be setup to point to your ingress controller
DASHBOARD_URL=dashboard.domain.tld
kubectl apply -n tekton-pipelines -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tekton-dashboard
  namespace: tekton-pipelines
spec:
  rules:
  - host: $DASHBOARD_URL
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: tekton-dashboard
            port:
              number: 9097
EOF

You can now access the Dashboard UI at http(s)://dashboard.domain.tld in your browser (assuming the host configured in the ingress is dashboard.domain.tld)

Notes:

The exact Ingress resource definition may vary a little depending on the ingress controller installed in the cluster. Some specific annotations may be required for the ingress controller to process the Ingress resource correctly
If you don’t have access to a domain you can use the freely available nip.io service

An example using the NGINX ingress controller to expose the Dashboard on a specific path instead of at the root of the domain:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tekton-dashboard
  namespace: tekton-pipelines
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - host: domain.tld
    http:
      paths:
      - path: /tekton(/|$)(.*)
        backend:
          service:
            name: tekton-dashboard
            port:
              number: 9097

You can then access the Dashboard UI at http(s)://domain.tld/tekton/

Access control

See the walk-throughs for an example of enabling authentication using oauth2-proxy.

kubectl delete clusterrolebinding -l rbac.dashboard.tekton.dev/subject=tekton-dashboard
kubectl delete rolebinding -l rbac.dashboard.tekton.dev/subject=tekton-dashboard -n tekton-pipelines

oauth2-proxy: add the --pass-authorization-header=false command line argument or its equivalent to your config https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/overview#command-line-options
Istio EnvoyFilter: the external authentication service should return a custom header x-envoy-auth-headers-to-remove: Authorization https://www.envoyproxy.io/docs/envoy/latest/api-v3/service/auth/v3/external_auth.proto
Traefik: removeHeader: true https://doc.traefik.io/traefik/v2.0/middlewares/basicauth/#removeheader

Uninstalling the Dashboard on Kubernetes

The Dashboard can be uninstalled by running the following command:

kubectl delete --filename https://infra.tekton.dev/tekton-releases/dashboard/latest/release.yaml

The above command assumes that the current latest version was installed, refer to Installing Tekton Dashboard on Kubernetes to find the correct --filename argument if another version was installed.

Next steps

To get started with Tekton Dashboard, see the tutorial.

To add more functionality to your Tekton Dashboard, see the Tekton Dashboard extensions

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License. Code samples are licensed under the Apache 2.0 License.

Docs: Install and set up Tekton Triggers

Mon, 01 Jan 0001 00:00:00 +0000

This document shows you how to install and set up Tekton Triggers.

Prerequisites

Kubernetes cluster version 1.18 or later.
Kubectl.
Tekton Pipelines.
Grant cluster-admin privileges to the user that installed Tekton Pipelines. See the kubernetes role-based access control (RBAC) docs.

Installation

Log on to your Kubernetes cluster with the same user account that installed Tekton Pipelines.

Depending on which version of Tekton Triggers you want to install, run one of the following commands:

Latest official release

kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/latest/release.yaml
kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/latest/interceptors.yaml

Nightly release

kubectl apply --filename \
https://storage.googleapis.com/tekton-releases-nightly/triggers/latest/release.yaml
kubectl apply --filename \
https://storage.googleapis.com/tekton-releases-nightly/triggers/latest/interceptors.yaml

Specific Release

kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/previous/VERSION_NUMBER/release.yaml
kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/previous/VERSION_NUMBER/interceptors.yaml

Replace VERSION_NUMBER with the numbered version you want to install. For example, v0.19.1.

Untagged Release

If your container runtime does not support image-reference:tag@digest (for example, cri-o used in OpenShift 4.x):

kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/latest/release.notags.yaml
kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/latest/interceptors.notags.yaml

To monitor the installation, run:
```
kubectl get pods --namespace tekton-pipelines --watch
```
When all components show 1/1 under the READY column, the installation is complete. Hit Ctrl + C to stop monitoring.

Customization options

You can customize the behavior of the Triggers Controller changing some values in the config/feature-flags-triggers.yaml file.

Enable alpha features. Set the value of enable-api-fields: to "alpha", the default value is "stable". This flag only applies to the v1beta1 API version.
Exclude labels. Set the labels-exclusion-pattern: field to a regex pattern. Labels that match this pattern are excluded from getting added to the resources created by the EventListener. By default this field is empty, so all labels added to the EventListener are propagated down.

Vault: Install and set up Tekton Triggers

Mon, 01 Jan 0001 00:00:00 +0000

This document shows you how to install and set up Tekton Triggers.

Prerequisites

Kubernetes cluster version 1.18 or later.
Kubectl.
Tekton Pipelines.
Grant cluster-admin privileges to the user that installed Tekton Pipelines. See the kubernetes role-based access control (RBAC) docs.

Installation

Log on to your Kubernetes cluster with the same user account that installed Tekton Pipelines.

Depending on which version of Tekton Triggers you want to install, run one of the following commands:

Latest official release

kubectl apply --filename \
https://infra.tekton.dev/tekton-releases/triggers/latest/release.yaml
kubectl apply --filename \
https://infra.tekton.dev/tekton-releases/triggers/latest/interceptors.yaml

Nightly release

kubectl apply --filename \
https://infra.tekton.dev/tekton-releases-nightly/triggers/latest/release.yaml
kubectl apply --filename \
https://infra.tekton.dev/tekton-releases-nightly/triggers/latest/interceptors.yaml

Specific Release

kubectl apply --filename \
https://infra.tekton.dev/tekton-releases/triggers/previous/VERSION_NUMBER/release.yaml
kubectl apply --filename \
https://infra.tekton.dev/tekton-releases/triggers/previous/VERSION_NUMBER/interceptors.yaml

Replace VERSION_NUMBER with the numbered version you want to install. For example, v0.19.1.

Untagged Release

If your container runtime does not support image-reference:tag@digest (for example, cri-o used in OpenShift 4.x):

kubectl apply --filename \
https://infra.tekton.dev/tekton-releases/triggers/latest/release.notags.yaml
kubectl apply --filename \
https://infra.tekton.dev/tekton-releases/triggers/latest/interceptors.notags.yaml

To monitor the installation, run:
```
kubectl get pods --namespace tekton-pipelines --watch
```
When all components show 1/1 under the READY column, the installation is complete. Hit Ctrl + C to stop monitoring.

Customization options

You can customize the behavior of the Triggers Controller changing some values in the config/feature-flags-triggers.yaml file.

Enable alpha features. Set the value of enable-api-fields: to "alpha", the default value is "stable". This flag only applies to the v1beta1 API version.
Exclude labels. Set the labels-exclusion-pattern: field to a regex pattern. Labels that match this pattern are excluded from getting added to the resources created by the EventListener. By default this field is empty, so all labels added to the EventListener are propagated down.

Vault: Install and set up Tekton Triggers

Mon, 01 Jan 0001 00:00:00 +0000

This document shows you how to install and set up Tekton Triggers.

Prerequisites

Kubernetes cluster version 1.18 or later.
Kubectl.
Tekton Pipelines.
Grant cluster-admin privileges to the user that installed Tekton Pipelines. See the kubernetes role-based access control (RBAC) docs.

Installation

Log on to your Kubernetes cluster with the same user account that installed Tekton Pipelines.

Depending on which version of Tekton Triggers you want to install, run one of the following commands:

Latest official release

kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/latest/release.yaml
kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/latest/interceptors.yaml

Nightly release

kubectl apply --filename \
https://storage.googleapis.com/tekton-releases-nightly/triggers/latest/release.yaml
kubectl apply --filename \
https://storage.googleapis.com/tekton-releases-nightly/triggers/latest/interceptors.yaml

Specific Release

kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/previous/VERSION_NUMBER/release.yaml
kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/previous/VERSION_NUMBER/interceptors.yaml

Replace VERSION_NUMBER with the numbered version you want to install. For example, v0.19.1.

Untagged Release

If your container runtime does not support image-reference:tag@digest (for example, cri-o used in OpenShift 4.x):

kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/latest/release.notags.yaml
kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/latest/interceptors.notags.yaml

To monitor the installation, run:
```
kubectl get pods --namespace tekton-pipelines --watch
```
When all components show 1/1 under the READY column, the installation is complete. Hit Ctrl + C to stop monitoring.

Customization options

You can customize the behavior of the Triggers Controller changing some values in the config/feature-flags-triggers.yaml file.

Enable alpha features. Set the value of enable-api-fields: to "alpha", the default value is "stable". This flag only applies to the v1beta1 API version.
Exclude labels. Set the labels-exclusion-pattern: field to a regex pattern. Labels that match this pattern are excluded from getting added to the resources created by the EventListener. By default this field is empty, so all labels added to the EventListener are propagated down.

Vault: Install and set up Tekton Triggers

Mon, 01 Jan 0001 00:00:00 +0000

This document shows you how to install and set up Tekton Triggers.

Prerequisites

Kubernetes cluster version 1.18 or later.
Kubectl.
Tekton Pipelines.
Grant cluster-admin privileges to the user that installed Tekton Pipelines. See the kubernetes role-based access control (RBAC) docs.

Installation

Log on to your Kubernetes cluster with the same user account that installed Tekton Pipelines.

Depending on which version of Tekton Triggers you want to install, run one of the following commands:

Latest official release

kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/latest/release.yaml
kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/latest/interceptors.yaml

Nightly release

kubectl apply --filename \
https://storage.googleapis.com/tekton-releases-nightly/triggers/latest/release.yaml
kubectl apply --filename \
https://storage.googleapis.com/tekton-releases-nightly/triggers/latest/interceptors.yaml

Specific Release

kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/previous/VERSION_NUMBER/release.yaml
kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/previous/VERSION_NUMBER/interceptors.yaml

Replace VERSION_NUMBER with the numbered version you want to install. For example, v0.19.1.

Untagged Release

If your container runtime does not support image-reference:tag@digest (for example, cri-o used in OpenShift 4.x):

kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/latest/release.notags.yaml
kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/latest/interceptors.notags.yaml

To monitor the installation, run:
```
kubectl get pods --namespace tekton-pipelines --watch
```
When all components show 1/1 under the READY column, the installation is complete. Hit Ctrl + C to stop monitoring.

Customization options

You can customize the behavior of the Triggers Controller changing some values in the config/feature-flags-triggers.yaml file.

Enable alpha features. Set the value of enable-api-fields: to "alpha", the default value is "stable". This flag only applies to the v1beta1 API version.
Exclude labels. Set the labels-exclusion-pattern: field to a regex pattern. Labels that match this pattern are excluded from getting added to the resources created by the EventListener. By default this field is empty, so all labels added to the EventListener are propagated down.

Docs: Install Tekton Pipelines

Mon, 01 Jan 0001 00:00:00 +0000

This page includes content about running Tekton with specific platforms and cloud providers. The accuracy and freshness of this vendor documentation varies by vendor.

If you want to contribute with platform-specific documentation, follow the vendor contributions guidelines.

This guide explains how to install Tekton Pipelines.

Prerequisites

A Kubernetes cluster running version 1.28 or later.
Kubectl.
Grant cluster-admin privileges to the current user. See the Kubernetes role-based access control (RBAC) docs for more information.
(Optional) Install a Metrics Server if you need support for high availability use cases.

See the local installation guide if you want to test Tekton on your computer.

Installation

To install Tekton Pipelines on a Kubernetes cluster:

Run one of the following commands depending on which version of Tekton Pipelines you want to install:
- Latest official release:
```
kubectl apply --filename https://infra.tekton.dev/tekton-releases/pipeline/latest/release.yaml
```
  Note: These instructions are ideal as a quick start installation guide with Tekton Pipelines and not meant for the production use. Please refer to the operator to install, upgrade and manage Tekton projects.
- Nightly release:
```
kubectl apply --filename https://infra.tekton.dev/tekton-releases-nightly/pipeline/latest/release.yaml
```
- Specific release:
```
 kubectl apply --filename https://infra.tekton.dev/tekton-releases/pipeline/previous/<version_number>/release.yaml
```
  Replace <version_number> with the numbered version you want to install. For example, v0.26.0.
- Untagged release:
  
  If your container runtime does not support image-reference:tag@digest:
```
kubectl apply --filename https://infra.tekton.dev/tekton-releases/pipeline/latest/release.notags.yaml
```

Multi-tenant installation is only partially supported today, read the guide for reference.

Monitor the installation:
```
kubectl get pods --namespace tekton-pipelines --watch
```
When all components show 1/1 under the READY column, the installation is complete. Hit Ctrl + C to stop monitoring.

Congratulations! You have successfully installed Tekton Pipelines on your Kubernetes cluster.

Before you proceed, create or select a project on Google Cloud and install the gcloud CLI on your computer.

To install Tekton Pipelines:

Enable the Google Kubernetes Engine (GKE) API:

gcloud services enable container.googleapis.com

Create a cluster with Workload Identity enabled. For example:
```
gcloud container clusters create tekton-cluster \
  --num-nodes=<nodes> \
  --region=<location> \
  --workload-pool=<project-id>.svc.id.goog
```
Where:
- <location> is the cluster location. For example, us-central1. See the documentation about regional and zonal clusters for more information.
- <project-id> is the project ID.
- <nodes> is the number of nodes.
Workload Identity allows your GKE cluster to access Google Cloud services using an Identity Access Management (IAM) service account. For example, the Tekton build and push guide explains how to authenticate to Artifact Registry on a cluster with Workload Identity enabled.

You can also enable Workload Idenitity on an existing cluster.
Follow the regular Kubernetes installation steps.

Private clusters

If you are running a private cluster and experience problems with GKE DNS resolution, allow the port 8443 in your firewall rules.

gcloud compute firewall-rules update <firewall_rule_name> --allow tcp:8443

See the documentation about firewall rules for private clusters for more information.

Autopilot

If you are using Autopilot mode on your GKE cluster and experience some problems, try the following:

Allow port 8443 in your firewall rules.

gcloud compute firewall-rules update <firewall_rule_name> --allow tcp:8443

Disable the affinity assistant.

kubectl patch cm feature-flags -n tekton-pipelines \
  -p '{"data":{"disable-affinity-assistant":"true"}}'

Increase the ephemeral storage.

To install Tekton Pipelines on OpenShift, you must first apply the anyuid security context constraint to the tekton-pipelines-controller service account. This is required to run the webhook Pod. See Security Context Constraints for more information.

Log on as a user with cluster-admin privileges. The following example uses the default system:admin user:
```
oc login -u system:admin
```

Set up the namespace (project) and configure the service account:

oc new-project tekton-pipelines
oc adm policy add-scc-to-user anyuid -z tekton-pipelines-controller
oc adm policy add-scc-to-user anyuid -z tekton-pipelines-webhook

Install Tekton Pipelines:

Because OpenShift uses random user id (and user id range per namespace) for pods, we need to remove the securityContext.runAsUser and securityContext.runAsGroup from any container from the release.yaml. You will need to have yq installed for this to work. Another way would be to download the yaml, search and replace (here replace with nothing) in your favourite editor.
```
curl https://storage.googleapis.com/tekton-releases/pipeline/latest/release.notags.yaml | yq 'del(.spec.template.spec.containers[].securityContext.runAsUser, .spec.template.spec.containers[].securityContext.runAsGroup)' | oc apply -f -
```
See the OpenShift CLI documentation for more information on the oc command.
Monitor the installation using the following command until all components show a Running status:
```
oc get pods --namespace tekton-pipelines --watch
```
Note: Hit CTRL + C to stop monitoring.

Congratulations! You have successfully installed Tekton Pipelines on your OpenShift environment.

To run OpenShift 4.x on your laptop (or desktop), take a look at Red Hat CodeReady Containers.

Additional configuration options

You can enable additional alpha and beta features, customize execution parameters, configure availability, and many more options. See the additional configuration options for more information.

Next steps

To get started with Tekton check the Introductory tutorials, the how-to guides, and the examples folder.

Source for this document available on GitHub.

Docs: Install and set up Tekton Triggers

Mon, 01 Jan 0001 00:00:00 +0000

This document shows you how to install and set up Tekton Triggers.

Prerequisites

Kubernetes cluster version 1.18 or later.
Kubectl.
Tekton Pipelines.
Grant cluster-admin privileges to the user that installed Tekton Pipelines. See the kubernetes role-based access control (RBAC) docs.

Installation

Log on to your Kubernetes cluster with the same user account that installed Tekton Pipelines.

Depending on which version of Tekton Triggers you want to install, run one of the following commands:

Latest official release

kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/latest/release.yaml
kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/latest/interceptors.yaml

Nightly release

kubectl apply --filename \
https://storage.googleapis.com/tekton-releases-nightly/triggers/latest/release.yaml
kubectl apply --filename \
https://storage.googleapis.com/tekton-releases-nightly/triggers/latest/interceptors.yaml

Specific Release

kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/previous/VERSION_NUMBER/release.yaml
kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/previous/VERSION_NUMBER/interceptors.yaml

Replace VERSION_NUMBER with the numbered version you want to install. For example, v0.19.1.

Untagged Release

If your container runtime does not support image-reference:tag@digest (for example, cri-o used in OpenShift 4.x):

kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/latest/release.notags.yaml
kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/latest/interceptors.notags.yaml

To monitor the installation, run:
```
kubectl get pods --namespace tekton-pipelines --watch
```
When all components show 1/1 under the READY column, the installation is complete. Hit Ctrl + C to stop monitoring.

Customization options

You can customize the behavior of the Triggers Controller changing some values in the config/feature-flags-triggers.yaml file.

Enable alpha features. Set the value of enable-api-fields: to "alpha", the default value is "stable". This flag only applies to the v1beta1 API version.
Exclude labels. Set the labels-exclusion-pattern: field to a regex pattern. Labels that match this pattern are excluded from getting added to the resources created by the EventListener. By default this field is empty, so all labels added to the EventListener are propagated down.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Pipeline

TektonPipeline custom resource allows user to install and manage Tekton Pipeline.

It is recommended to install the component through TektonConfig.

The TektonPipeline CR is as below:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonPipeline
metadata:
  name: pipeline
spec:
  targetNamespace: tekton-pipelines
  await-sidecar-readiness: true
  coschedule: workspaces
  disable-creds-init: false
  disable-home-env-overwrite: true
  disable-working-directory-overwrite: true
  disable-inline-spec: "taskrun,pipelinerun,pipeline"
  enable-api-fields: beta
  enable-bundles-resolver: true
  enable-cel-in-whenexpression: false
  enable-cluster-resolver: true
  enable-custom-tasks: true
  enable-git-resolver: true
  enable-hub-resolver: true
  enable-param-enum: false
  enable-provenance-in-status: true
  enable-step-actions: false
  enforce-nonfalsifiability: none
  keep-pod-on-cancel: false
  max-result-size: 4096
  metrics.count.enable-reason: false
  metrics.pipelinerun.duration-type: histogram
  metrics.pipelinerun.level: pipeline
  metrics.taskrun.duration-type: histogram
  metrics.taskrun.level: task
  # Tracing configuration (optional)
  # traces.enabled: true
  # traces.endpoint: "http://jaeger-collector.jaeger.svc.cluster.local:4318/v1/traces"
  # traces.credentialsSecret: ""
  require-git-ssh-secret-known-hosts: false
  results-from: termination-message
  running-in-environment-with-injected-sidecars: true
  send-cloudevents-for-runs: false
  set-security-context: false
  trusted-resources-verification-no-match-policy: ignore
  performance:
    disable-ha: false
    buckets: 1
    replicas: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10
    statefulset-ordinals: false
  options:
    disabled: false
    configMaps: {}
    deployments: {}

You can install this component using TektonConfig by choosing appropriate profile.

Properties

This fields have default values so even if user have not passed them in CR, operator will add them. User can later change them as per their need.

disable-creds-init (Default: false)

Setting this flag to “true” will prevent Tekton scanning attached service accounts and injecting any credentials it finds into your Steps.

The default behaviour currently is for Tekton to search service accounts for secrets matching a specified format and automatically mount those into your Steps.

Note: setting this to “true” will prevent PipelineResources from working. See more info here.
await-sidecar-readiness (Default: true)

Setting this flag to “false” to allow the Tekton controller to start a TasksRun’s first step immediately without waiting for sidecar containers to be running first.

Note: setting this flag to “false” will mean the running-in-environment-with-injected-sidecars flag has no effect.
coschedule (Default: workspaces)

This flag determines how PipelineRun Pods are scheduled with Affinity Assistant. Acceptable values are “workspaces” (default), “pipelineruns”, “isolate-pipelinerun”, or “disabled”
running-in-environment-with-injected-sidecars (Default: true)

This option should be set to false when Pipelines is running in a cluster that does not use injected sidecars such as Istio. Setting it to false should decrease the time it takes for a TaskRun to start running. For clusters that use injected sidecars, setting this option to false can lead to unexpected behavior.

See more info here.
require-git-ssh-secret-known-hosts (Default: false)

Setting this flag to “true” will require that any Git SSH Secret offered to Tekton must have known_hosts included.

See more info here.
enable-custom-tasks (Default: false)

Setting this flag to “true” enables the use of custom tasks from within pipelines. This is an experimental feature and thus should still be considered an alpha feature.
enable-api-fields (Default: stable)

Setting this flag will determine which gated features are enabled. Acceptable values are “stable” or “alpha”.
results-from (Default: termination-message)

This feature is to use the container’s termination message to fetch results from. Set it to “sidecar-logs” to enable use of a results sidecar logs to extract results instead of termination message.
max-result-size (Default: 4096)

This feature is to configure the size of the task results if using sidecar-logs. The default value if 4096 and maximum value can be 1572863.
enable-provenance-in-status (Default: true)

This feature is to enable populating the provenance field in TaskRun and PipelineRun status. The provenance field contains metadata about resources used in the TaskRun/PipelineRun such as the source from where a remote Task/Pipeline definition was fetched. To disable populating this field, set this flag to “false”.
set-security-context (Default: false)

Setting this flag to “true” to set a security context for containers injected by Tekton that will allow TaskRun pods to run in namespaces with restricted pod security admission
keep-pod-on-cancel (Default: false)

Setting this flag to “true” will not delete the pod associated with cancelled taskrun.
enforce-nonfalsifiability (Default: none)

Setting this flag to “spire” to enable integration with SPIRE.
enable-param-enum (Default: false)

Setting this flag to “true” will enable params of type Enum
enable-step-actions (Default: false)

Setting this flag to “true” will enable specifying StepAction in a Step. A StepAction is the reusable and scriptable unit of work that is performed by a Step
enable-cel-in-whenexpression (Default: false)

Setting this flag to “true” will enable using CEL in when expressions.
trusted-resources-verification-no-match-policy (Default: ignore)

Trusted Resources is a feature which can be used to sign Tekton Resources and verify them. Details of design can be found at TEP–0091. This feature is under alpha version and support v1beta1 version of Task and Pipeline. To know more about this visit pipelines documentation

Metrics Properties

These fields have default values so even if user have not passed them in CR, operator will add them and override the values configure in pipelines.

metrics.pipelinerun.duration-type (Default: histogram)

Setting this flag will determine the duration type - gauge or histogram.
metrics.pipelinerun.level (Default: pipeline)

Setting this flag will determine the level of pipelinerun metrics.
metrics.taskrun.duration-type (Default: histogram)

Setting this flag will determine the duration type - gauge or histogram.
metrics.taskrun.level (Default: task)

Setting this flag will determine the level of taskrun metrics.
metrics.count.enable-reason (Default: false)

Setting this flag to “true” will include reason label on count metrics.

Tracing Properties

Tekton Pipelines supports distributed tracing using OpenTelemetry. These fields allow you to configure tracing to send trace data to observability backends like Jaeger, Zipkin, or other OTLP-compatible collectors.

traces.enabled (Optional)

Setting this flag to “true” enables distributed tracing for Tekton Pipelines. When enabled, the pipeline controller will export trace spans for pipeline and task reconciliation operations.
```
spec:
  traces.enabled: true
```
traces.endpoint (Optional)

The URL of the OpenTelemetry trace collector endpoint. Tekton Pipeline exports traces using the OTLP (OpenTelemetry Protocol) format over HTTP.

Supported endpoints:
- Jaeger with OTLP: Use port 4318 for OTLP HTTP (e.g., http://jaeger-collector.jaeger.svc.cluster.local:4318/v1/traces)
- OpenTelemetry Collector: OTLP HTTP endpoint (e.g., http://otel-collector.observability.svc.cluster.local:4318/v1/traces)
- Other OTLP-compatible backends: Any trace backend that supports OTLP HTTP protocol
```
spec:
  traces.enabled: true
  traces.endpoint: "http://jaeger-collector.jaeger.svc.cluster.local:4318/v1/traces"
```
traces.credentialsSecret (Optional)

The name of a Kubernetes secret containing credentials for authenticating with the tracing endpoint. This is useful when your tracing backend requires authentication.
```
spec:
  traces.enabled: true
  traces.endpoint: "https://secure-jaeger-collector.example.com/api/traces"
  traces.credentialsSecret: "jaeger-auth-secret"
```

Example: Complete Tracing Configuration

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonPipeline
metadata:
  name: pipeline
spec:
  targetNamespace: tekton-pipelines
  # ... other configuration ...

  # Enable tracing with OpenTelemetry Collector
  traces.enabled: true
  traces.endpoint: "http://otel-collector.observability.svc.cluster.local:4318/v1/traces"

Example: Tracing with Jaeger

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonPipeline
metadata:
  name: pipeline
spec:
  targetNamespace: tekton-pipelines
  # ... other configuration ...

  # Enable tracing with Jaeger (using OTLP endpoint)
  traces.enabled: true
  traces.endpoint: "http://jaeger-collector.jaeger.svc.cluster.local:4318/v1/traces"

For more information about distributed tracing in Tekton Pipelines, see the TEP-0124: Distributed Tracing for Tasks and Pipelines.

Optional Properties

This fields doesn’t have default values so will be considered only if user passes them. By default Operator won’t add this fields CR and won’t configure for pipelines.

The Default values for this fields are already set in pipelines are not set by Operator. If user passes some values then those will be set for the particular field.

default-timeout-minutes

default-timeout-minutes contains the default number of minutes to use for TaskRun and PipelineRun, if none is specified.

default-timeout-minutes: "60" # 60 minutes
default-service-account

default-service-account contains the default service account name to use for TaskRun and PipelineRun, if none is specified.

default-service-account: "default"
default-managed-by-label-value

default-managed-by-label-value contains the default value given to the “app.kubernetes.io/managed-by” label applied to all Pods created for TaskRuns. If a user’s requested TaskRun specifies another value for this label, the user’s request supersedes.

default-managed-by-label-value: "tekton-pipelines"
disable-inline-spec (Default: ``)

Inline specifications can be disabled for specific resources only. To achieve that, set the disable-inline-spec flag to a comma-separated list of the desired resources. Valid values are pipeline, pipelinerun and taskrun.
default-pod-template

default-pod-template contains the default pod template to use TaskRun and PipelineRun, if none is specified. If a pod template is specified, the default pod template is ignored.
default-cloud-events-sink

default-cloud-events-sink contains the default CloudEvents sink to be used for TaskRun and PipelineRun, when no sink is specified. Note that right now it is still not possible to set a PipelineRun or TaskRun specific sink, so the default is the only option available. If no sink is specified, no CloudEvent is generated
default-task-run-workspace-binding

default-task-run-workspace-binding contains the default workspace configuration provided for any Workspaces that a Task declares but that a TaskRun does not explicitly provide.
default-resolver-type

default-resolver-type contains the resolver type to be used as default resolver.

Performance Properties

spec:
  # omitted other fields ...
  performance:
    disable-ha: false
    buckets: 1
    replicas: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10
    statefulset-ordinals: false

These fields are optional and there is no default values. If user passes them, operator will include most of fields into the deployment tekton-pipelines-controller under the container tekton-pipelines-controller as arguments(duplicate name? No, container and deployment has the same name), otherwise pipelines controller’s default values will be considered. and buckets field is updated into config-leader-election config-map under the namespace tekton-pipelines.

A high level descriptions are given here. To get the detailed information please visit pipelines documentation, High Availability Support, and Performance Configuration

disable-ha - enable or disable ha feature, defaults in pipelines controller is disable-ha=false
buckets - buckets is the number of buckets used to partition key space of each reconciler. If this number is M and the replica number of the controller is N, the N replicas will compete for the M buckets. The owner of a bucket will take care of the reconciling for the keys partitioned into that bucket. The maximum value of buckets at this time is 10. default value in pipeline controller is 1
replicas - pipelines controller deployment replicas count
threads-per-controller - is the number of threads(aka worker) to use when processing the pipelines controller’s workqueue, default value in pipelines controller is 2
kube-api-qps - QPS indicates the maximum QPS to the cluster master from the REST client, default value in pipeline controller is 5.0
kube-api-burst - maximum burst for throttle, default value in pipeline controller is 10
statefulset-ordinals - enables StatefulSet Ordinals mode for the Tekton Pipelines Controller. When set to true, the Pipelines Controller is deployed as a StatefulSet, allowing for multiple replicas to be configured with a load-balancing mode. This ensures that the load is evenly distributed across replicas, and the number of buckets is enforced to match the number of replicas. Moreover, There are two mechanisms available for scaling for scaling Pipelines Controller horizontally:

Using leader election, which allows for failover, but can result in hot-spotting.
Using StatefulSet ordinals, which doesn’t allow for failover, but guarantees load is evenly spread across replicas.

Note:

kube-api-qps and kube-api-burst will be multiplied by 2 in pipelines controller. To get the detailed information visit Performance Configuration guide

if you modify or remove any of the performance properties, tekton-pipelines-controller deployment and config-leader-election config-map (if buckets changed) will be updated, and tekton-pipelines-controller pods will be recreated

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Pipeline

TektonPipeline custom resource allows user to install and manage Tekton Pipeline.

It is recommended to install the component through TektonConfig.

The TektonPipeline CR is as below:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonPipeline
metadata:
  name: pipeline
spec:
  targetNamespace: tekton-pipelines
  await-sidecar-readiness: true
  coschedule: workspaces
  disable-creds-init: false
  disable-home-env-overwrite: true
  disable-working-directory-overwrite: true
  disable-inline-spec: "taskrun,pipelinerun,pipeline"
  enable-api-fields: beta
  enable-bundles-resolver: true
  enable-cel-in-whenexpression: false
  enable-cluster-resolver: true
  enable-custom-tasks: true
  enable-git-resolver: true
  enable-hub-resolver: true
  enable-param-enum: false
  enable-provenance-in-status: true
  enable-step-actions: false
  enforce-nonfalsifiability: none
  keep-pod-on-cancel: false
  max-result-size: 4096
  metrics.count.enable-reason: false
  metrics.pipelinerun.duration-type: histogram
  metrics.pipelinerun.level: pipeline
  metrics.taskrun.duration-type: histogram
  metrics.taskrun.level: task
  # Tracing configuration (optional)
  # traces.enabled: true
  # traces.endpoint: "http://jaeger-collector.jaeger.svc.cluster.local:4318/v1/traces"
  # traces.credentialsSecret: ""
  require-git-ssh-secret-known-hosts: false
  results-from: termination-message
  running-in-environment-with-injected-sidecars: true
  send-cloudevents-for-runs: false
  set-security-context: false
  trusted-resources-verification-no-match-policy: ignore
  performance:
    disable-ha: false
    buckets: 1
    replicas: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10
    statefulset-ordinals: false
  options:
    disabled: false
    configMaps: {}
    deployments: {}

You can install this component using TektonConfig by choosing appropriate profile.

Properties

This fields have default values so even if user have not passed them in CR, operator will add them. User can later change them as per their need.

disable-creds-init (Default: false)

Setting this flag to “true” will prevent Tekton scanning attached service accounts and injecting any credentials it finds into your Steps.

The default behaviour currently is for Tekton to search service accounts for secrets matching a specified format and automatically mount those into your Steps.

Note: setting this to “true” will prevent PipelineResources from working. See more info here.
await-sidecar-readiness (Default: true)

Setting this flag to “false” to allow the Tekton controller to start a TasksRun’s first step immediately without waiting for sidecar containers to be running first.

Note: setting this flag to “false” will mean the running-in-environment-with-injected-sidecars flag has no effect.
coschedule (Default: workspaces)

This flag determines how PipelineRun Pods are scheduled with Affinity Assistant. Acceptable values are “workspaces” (default), “pipelineruns”, “isolate-pipelinerun”, or “disabled”
running-in-environment-with-injected-sidecars (Default: true)

This option should be set to false when Pipelines is running in a cluster that does not use injected sidecars such as Istio. Setting it to false should decrease the time it takes for a TaskRun to start running. For clusters that use injected sidecars, setting this option to false can lead to unexpected behavior.

See more info here.
require-git-ssh-secret-known-hosts (Default: false)

Setting this flag to “true” will require that any Git SSH Secret offered to Tekton must have known_hosts included.

See more info here.
enable-custom-tasks (Default: false)

Setting this flag to “true” enables the use of custom tasks from within pipelines. This is an experimental feature and thus should still be considered an alpha feature.
enable-api-fields (Default: stable)

Setting this flag will determine which gated features are enabled. Acceptable values are “stable” or “alpha”.
results-from (Default: termination-message)

This feature is to use the container’s termination message to fetch results from. Set it to “sidecar-logs” to enable use of a results sidecar logs to extract results instead of termination message.
max-result-size (Default: 4096)

This feature is to configure the size of the task results if using sidecar-logs. The default value if 4096 and maximum value can be 1572863.
enable-provenance-in-status (Default: true)

This feature is to enable populating the provenance field in TaskRun and PipelineRun status. The provenance field contains metadata about resources used in the TaskRun/PipelineRun such as the source from where a remote Task/Pipeline definition was fetched. To disable populating this field, set this flag to “false”.
set-security-context (Default: false)

Setting this flag to “true” to set a security context for containers injected by Tekton that will allow TaskRun pods to run in namespaces with restricted pod security admission
keep-pod-on-cancel (Default: false)

Setting this flag to “true” will not delete the pod associated with cancelled taskrun.
enforce-nonfalsifiability (Default: none)

Setting this flag to “spire” to enable integration with SPIRE.
enable-param-enum (Default: false)

Setting this flag to “true” will enable params of type Enum
enable-step-actions (Default: false)

Setting this flag to “true” will enable specifying StepAction in a Step. A StepAction is the reusable and scriptable unit of work that is performed by a Step
enable-cel-in-whenexpression (Default: false)

Setting this flag to “true” will enable using CEL in when expressions.
trusted-resources-verification-no-match-policy (Default: ignore)

Trusted Resources is a feature which can be used to sign Tekton Resources and verify them. Details of design can be found at TEP–0091. This feature is under alpha version and support v1beta1 version of Task and Pipeline. To know more about this visit pipelines documentation

Metrics Properties

These fields have default values so even if user have not passed them in CR, operator will add them and override the values configure in pipelines.

metrics.pipelinerun.duration-type (Default: histogram)

Setting this flag will determine the duration type - gauge or histogram.
metrics.pipelinerun.level (Default: pipeline)

Setting this flag will determine the level of pipelinerun metrics.
metrics.taskrun.duration-type (Default: histogram)

Setting this flag will determine the duration type - gauge or histogram.
metrics.taskrun.level (Default: task)

Setting this flag will determine the level of taskrun metrics.
metrics.count.enable-reason (Default: false)

Setting this flag to “true” will include reason label on count metrics.

Tracing Properties

traces.enabled (Optional)

Setting this flag to “true” enables distributed tracing for Tekton Pipelines. When enabled, the pipeline controller will export trace spans for pipeline and task reconciliation operations.
```
spec:
  traces.enabled: true
```
traces.endpoint (Optional)

The URL of the OpenTelemetry trace collector endpoint. Tekton Pipeline exports traces using the OTLP (OpenTelemetry Protocol) format over HTTP.

Supported endpoints:
- Jaeger with OTLP: Use port 4318 for OTLP HTTP (e.g., http://jaeger-collector.jaeger.svc.cluster.local:4318/v1/traces)
- OpenTelemetry Collector: OTLP HTTP endpoint (e.g., http://otel-collector.observability.svc.cluster.local:4318/v1/traces)
- Other OTLP-compatible backends: Any trace backend that supports OTLP HTTP protocol
```
spec:
  traces.enabled: true
  traces.endpoint: "http://jaeger-collector.jaeger.svc.cluster.local:4318/v1/traces"
```
traces.credentialsSecret (Optional)

The name of a Kubernetes secret containing credentials for authenticating with the tracing endpoint. This is useful when your tracing backend requires authentication.
```
spec:
  traces.enabled: true
  traces.endpoint: "https://secure-jaeger-collector.example.com/api/traces"
  traces.credentialsSecret: "jaeger-auth-secret"
```

Example: Complete Tracing Configuration

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonPipeline
metadata:
  name: pipeline
spec:
  targetNamespace: tekton-pipelines
  # ... other configuration ...

  # Enable tracing with OpenTelemetry Collector
  traces.enabled: true
  traces.endpoint: "http://otel-collector.observability.svc.cluster.local:4318/v1/traces"

Example: Tracing with Jaeger

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonPipeline
metadata:
  name: pipeline
spec:
  targetNamespace: tekton-pipelines
  # ... other configuration ...

  # Enable tracing with Jaeger (using OTLP endpoint)
  traces.enabled: true
  traces.endpoint: "http://jaeger-collector.jaeger.svc.cluster.local:4318/v1/traces"

For more information about distributed tracing in Tekton Pipelines, see the TEP-0124: Distributed Tracing for Tasks and Pipelines.

Optional Properties

This fields doesn’t have default values so will be considered only if user passes them. By default Operator won’t add this fields CR and won’t configure for pipelines.

The Default values for this fields are already set in pipelines are not set by Operator. If user passes some values then those will be set for the particular field.

default-timeout-minutes

default-timeout-minutes contains the default number of minutes to use for TaskRun and PipelineRun, if none is specified.

default-timeout-minutes: "60" # 60 minutes
default-service-account

default-service-account contains the default service account name to use for TaskRun and PipelineRun, if none is specified.

default-service-account: "default"
default-managed-by-label-value

default-managed-by-label-value contains the default value given to the “app.kubernetes.io/managed-by” label applied to all Pods created for TaskRuns. If a user’s requested TaskRun specifies another value for this label, the user’s request supersedes.

default-managed-by-label-value: "tekton-pipelines"
disable-inline-spec (Default: ``)

Inline specifications can be disabled for specific resources only. To achieve that, set the disable-inline-spec flag to a comma-separated list of the desired resources. Valid values are pipeline, pipelinerun and taskrun.
default-pod-template

default-pod-template contains the default pod template to use TaskRun and PipelineRun, if none is specified. If a pod template is specified, the default pod template is ignored.
default-cloud-events-sink

default-cloud-events-sink contains the default CloudEvents sink to be used for TaskRun and PipelineRun, when no sink is specified. Note that right now it is still not possible to set a PipelineRun or TaskRun specific sink, so the default is the only option available. If no sink is specified, no CloudEvent is generated
default-task-run-workspace-binding

default-task-run-workspace-binding contains the default workspace configuration provided for any Workspaces that a Task declares but that a TaskRun does not explicitly provide.
default-resolver-type

default-resolver-type contains the resolver type to be used as default resolver.

Performance Properties

spec:
  # omitted other fields ...
  performance:
    disable-ha: false
    buckets: 1
    replicas: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10
    statefulset-ordinals: false

A high level descriptions are given here. To get the detailed information please visit pipelines documentation, High Availability Support, and Performance Configuration

disable-ha - enable or disable ha feature, defaults in pipelines controller is disable-ha=false
buckets - buckets is the number of buckets used to partition key space of each reconciler. If this number is M and the replica number of the controller is N, the N replicas will compete for the M buckets. The owner of a bucket will take care of the reconciling for the keys partitioned into that bucket. The maximum value of buckets at this time is 10. default value in pipeline controller is 1
replicas - pipelines controller deployment replicas count
threads-per-controller - is the number of threads(aka worker) to use when processing the pipelines controller’s workqueue, default value in pipelines controller is 2
kube-api-qps - QPS indicates the maximum QPS to the cluster master from the REST client, default value in pipeline controller is 5.0
kube-api-burst - maximum burst for throttle, default value in pipeline controller is 10
statefulset-ordinals - enables StatefulSet Ordinals mode for the Tekton Pipelines Controller. When set to true, the Pipelines Controller is deployed as a StatefulSet, allowing for multiple replicas to be configured with a load-balancing mode. This ensures that the load is evenly distributed across replicas, and the number of buckets is enforced to match the number of replicas. Moreover, There are two mechanisms available for scaling for scaling Pipelines Controller horizontally:

Using leader election, which allows for failover, but can result in hot-spotting.
Using StatefulSet ordinals, which doesn’t allow for failover, but guarantees load is evenly spread across replicas.

Note:

kube-api-qps and kube-api-burst will be multiplied by 2 in pipelines controller. To get the detailed information visit Performance Configuration guide

if you modify or remove any of the performance properties, tekton-pipelines-controller deployment and config-leader-election config-map (if buckets changed) will be updated, and tekton-pipelines-controller pods will be recreated

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Pipeline

TektonPipeline custom resource allows user to install and manage Tekton Pipeline.

It is recommended to install the component through TektonConfig.

The TektonPipeline CR is as below:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonPipeline
metadata:
  name: pipeline
spec:
  targetNamespace: tekton-pipelines
  await-sidecar-readiness: true
  coschedule: workspaces
  disable-affinity-assistant: false
  disable-creds-init: false
  disable-home-env-overwrite: true
  disable-working-directory-overwrite: true
  disable-inline-spec: "taskrun,pipelinerun,pipeline"
  enable-api-fields: beta
  enable-bundles-resolver: true
  enable-cel-in-whenexpression: false
  enable-cluster-resolver: true
  enable-custom-tasks: true
  enable-git-resolver: true
  enable-hub-resolver: true
  enable-param-enum: false
  enable-provenance-in-status: true
  enable-step-actions: false
  enforce-nonfalsifiability: none
  keep-pod-on-cancel: false
  max-result-size: 4096
  metrics.count.enable-reason: false
  metrics.pipelinerun.duration-type: histogram
  metrics.pipelinerun.level: pipeline
  metrics.taskrun.duration-type: histogram
  metrics.taskrun.level: task
  require-git-ssh-secret-known-hosts: false
  results-from: termination-message
  running-in-environment-with-injected-sidecars: true
  send-cloudevents-for-runs: false
  set-security-context: false
  trusted-resources-verification-no-match-policy: ignore
  performance:
    disable-ha: false
    buckets: 1
    replicas: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10
  options:
    disabled: false
    configMaps: {}
    deployments: {}

You can install this component using TektonConfig by choosing appropriate profile.

Properties

This fields have default values so even if user have not passed them in CR, operator will add them. User can later change them as per their need.

disable-affinity-assistant (Default: false)

Setting this flag to “true” will prevent Tekton to create an Affinity Assistant for every TaskRun sharing a PVC workspace. The default behaviour is for Tekton to create Affinity Assistants.

See more in the workspace documentation about Affinity Assistant or more info here.
disable-creds-init (Default: false)

Setting this flag to “true” will prevent Tekton scanning attached service accounts and injecting any credentials it finds into your Steps.

The default behaviour currently is for Tekton to search service accounts for secrets matching a specified format and automatically mount those into your Steps.

Note: setting this to “true” will prevent PipelineResources from working. See more info here.
await-sidecar-readiness (Default: true)

Setting this flag to “false” to allow the Tekton controller to start a TasksRun’s first step immediately without waiting for sidecar containers to be running first.

Note: setting this flag to “false” will mean the running-in-environment-with-injected-sidecars flag has no effect.
coschedule (Default: workspaces)

This flag determines how PipelineRun Pods are scheduled with Affinity Assistant. Acceptable values are “workspaces” (default), “pipelineruns”, “isolate-pipelinerun”, or “disabled”
running-in-environment-with-injected-sidecars (Default: true)

This option should be set to false when Pipelines is running in a cluster that does not use injected sidecars such as Istio. Setting it to false should decrease the time it takes for a TaskRun to start running. For clusters that use injected sidecars, setting this option to false can lead to unexpected behavior.

See more info here.
require-git-ssh-secret-known-hosts (Default: false)

Setting this flag to “true” will require that any Git SSH Secret offered to Tekton must have known_hosts included.

See more info here.
enable-custom-tasks (Default: false)

Setting this flag to “true” enables the use of custom tasks from within pipelines. This is an experimental feature and thus should still be considered an alpha feature.
enable-api-fields (Default: stable)

Setting this flag will determine which gated features are enabled. Acceptable values are “stable” or “alpha”.
results-from (Default: termination-message)

This feature is to use the container’s termination message to fetch results from. Set it to “sidecar-logs” to enable use of a results sidecar logs to extract results instead of termination message.
max-result-size (Default: 4096)

This feature is to configure the size of the task results if using sidecar-logs. The default value if 4096 and maximum value can be 1572863.
enable-provenance-in-status (Default: true)

This feature is to enable populating the provenance field in TaskRun and PipelineRun status. The provenance field contains metadata about resources used in the TaskRun/PipelineRun such as the source from where a remote Task/Pipeline definition was fetched. To disable populating this field, set this flag to “false”.
set-security-context (Default: false)

Setting this flag to “true” to set a security context for containers injected by Tekton that will allow TaskRun pods to run in namespaces with restricted pod security admission
keep-pod-on-cancel (Default: false)

Setting this flag to “true” will not delete the pod associated with cancelled taskrun.
enforce-nonfalsifiability (Default: none)

Setting this flag to “spire” to enable integration with SPIRE.
enable-param-enum (Default: false)

Setting this flag to “true” will enable params of type Enum
enable-step-actions (Default: false)

Setting this flag to “true” will enable specifying StepAction in a Step. A StepAction is the reusable and scriptable unit of work that is performed by a Step
enable-cel-in-whenexpression (Default: false)

Setting this flag to “true” will enable using CEL in when expressions.
trusted-resources-verification-no-match-policy (Default: ignore)

Trusted Resources is a feature which can be used to sign Tekton Resources and verify them. Details of design can be found at TEP–0091. This feature is under alpha version and support v1beta1 version of Task and Pipeline. To know more about this visit pipelines documentation

Metrics Properties

These fields have default values so even if user have not passed them in CR, operator will add them and override the values configure in pipelines.

metrics.pipelinerun.duration-type (Default: histogram)

Setting this flag will determine the duration type - gauge or histogram.
metrics.pipelinerun.level (Default: pipeline)

Setting this flag will determine the level of pipelinerun metrics.
metrics.taskrun.duration-type (Default: histogram)

Setting this flag will determine the duration type - gauge or histogram.
metrics.taskrun.level (Default: task)

Setting this flag will determine the level of taskrun metrics.
metrics.count.enable-reason (Default: false)

Setting this flag to “true” will include reason label on count metrics.

Optional Properties

This fields doesn’t have default values so will be considered only if user passes them. By default Operator won’t add this fields CR and won’t configure for pipelines.

The Default values for this fields are already set in pipelines are not set by Operator. If user passes some values then those will be set for the particular field.

default-timeout-minutes

default-timeout-minutes contains the default number of minutes to use for TaskRun and PipelineRun, if none is specified.

default-timeout-minutes: "60" # 60 minutes
default-service-account

default-service-account contains the default service account name to use for TaskRun and PipelineRun, if none is specified.

default-service-account: "default"
default-managed-by-label-value

default-managed-by-label-value contains the default value given to the “app.kubernetes.io/managed-by” label applied to all Pods created for TaskRuns. If a user’s requested TaskRun specifies another value for this label, the user’s request supersedes.

default-managed-by-label-value: "tekton-pipelines"
disable-inline-spec (Default: ``)

Inline specifications can be disabled for specific resources only. To achieve that, set the disable-inline-spec flag to a comma-separated list of the desired resources. Valid values are pipeline, pipelinerun and taskrun.
default-pod-template

default-pod-template contains the default pod template to use TaskRun and PipelineRun, if none is specified. If a pod template is specified, the default pod template is ignored.
default-cloud-events-sink

default-cloud-events-sink contains the default CloudEvents sink to be used for TaskRun and PipelineRun, when no sink is specified. Note that right now it is still not possible to set a PipelineRun or TaskRun specific sink, so the default is the only option available. If no sink is specified, no CloudEvent is generated
default-task-run-workspace-binding

default-task-run-workspace-binding contains the default workspace configuration provided for any Workspaces that a Task declares but that a TaskRun does not explicitly provide.
default-resolver-type

default-resolver-type contains the resolver type to be used as default resolver.

Performance Properties

spec:
  # omitted other fields ...
  performance:
    disable-ha: false
    buckets: 1
    replicas: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10

A high level descriptions are given here. To get the detailed information please visit pipelines documentation, High Availability Support, and Performance Configuration

disable-ha - enable or disable ha feature, defaults in pipelines controller is disable-ha=false
buckets - buckets is the number of buckets used to partition key space of each reconciler. If this number is M and the replica number of the controller is N, the N replicas will compete for the M buckets. The owner of a bucket will take care of the reconciling for the keys partitioned into that bucket. The maximum value of buckets at this time is 10. default value in pipeline controller is 1
replicas - pipelines controller deployment replicas count
threads-per-controller - is the number of threads(aka worker) to use when processing the pipelines controller’s workqueue, default value in pipelines controller is 2
kube-api-qps - QPS indicates the maximum QPS to the cluster master from the REST client, default value in pipeline controller is 5.0
kube-api-burst - maximum burst for throttle, default value in pipeline controller is 10

Note:

kube-api-qps and kube-api-burst will be multiplied by 2 in pipelines controller. To get the detailed information visit Performance Configuration guide

if you modify or remove any of the performance properties, tekton-pipelines-controller deployment and config-leader-election config-map (if buckets changed) will be updated, and tekton-pipelines-controller pods will be recreated

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Pipeline

TektonPipeline custom resource allows user to install and manage Tekton Pipeline.

It is recommended to install the component through TektonConfig.

The TektonPipeline CR is as below:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonPipeline
metadata:
  name: pipeline
spec:
  targetNamespace: tekton-pipelines
  await-sidecar-readiness: true
  coschedule: workspaces
  disable-affinity-assistant: false
  disable-creds-init: false
  disable-home-env-overwrite: true
  disable-working-directory-overwrite: true
  disable-inline-spec: "taskrun,pipelinerun,pipeline"
  enable-api-fields: beta
  enable-bundles-resolver: true
  enable-cel-in-whenexpression: false
  enable-cluster-resolver: true
  enable-custom-tasks: true
  enable-git-resolver: true
  enable-hub-resolver: true
  enable-param-enum: false
  enable-provenance-in-status: true
  enable-step-actions: false
  enforce-nonfalsifiability: none
  keep-pod-on-cancel: false
  max-result-size: 4096
  metrics.count.enable-reason: false
  metrics.pipelinerun.duration-type: histogram
  metrics.pipelinerun.level: pipeline
  metrics.taskrun.duration-type: histogram
  metrics.taskrun.level: task
  require-git-ssh-secret-known-hosts: false
  results-from: termination-message
  running-in-environment-with-injected-sidecars: true
  send-cloudevents-for-runs: false
  set-security-context: false
  trusted-resources-verification-no-match-policy: ignore
  performance:
    disable-ha: false
    buckets: 1
    replicas: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10
    statefulset-ordinals: false
  options:
    disabled: false
    configMaps: {}
    deployments: {}

You can install this component using TektonConfig by choosing appropriate profile.

Properties

This fields have default values so even if user have not passed them in CR, operator will add them. User can later change them as per their need.

disable-affinity-assistant (Default: false)

Setting this flag to “true” will prevent Tekton to create an Affinity Assistant for every TaskRun sharing a PVC workspace. The default behaviour is for Tekton to create Affinity Assistants.

See more in the workspace documentation about Affinity Assistant or more info here.
disable-creds-init (Default: false)

Setting this flag to “true” will prevent Tekton scanning attached service accounts and injecting any credentials it finds into your Steps.

The default behaviour currently is for Tekton to search service accounts for secrets matching a specified format and automatically mount those into your Steps.

Note: setting this to “true” will prevent PipelineResources from working. See more info here.
await-sidecar-readiness (Default: true)

Setting this flag to “false” to allow the Tekton controller to start a TasksRun’s first step immediately without waiting for sidecar containers to be running first.

Note: setting this flag to “false” will mean the running-in-environment-with-injected-sidecars flag has no effect.
coschedule (Default: workspaces)

This flag determines how PipelineRun Pods are scheduled with Affinity Assistant. Acceptable values are “workspaces” (default), “pipelineruns”, “isolate-pipelinerun”, or “disabled”
running-in-environment-with-injected-sidecars (Default: true)

This option should be set to false when Pipelines is running in a cluster that does not use injected sidecars such as Istio. Setting it to false should decrease the time it takes for a TaskRun to start running. For clusters that use injected sidecars, setting this option to false can lead to unexpected behavior.

See more info here.
require-git-ssh-secret-known-hosts (Default: false)

Setting this flag to “true” will require that any Git SSH Secret offered to Tekton must have known_hosts included.

See more info here.
enable-custom-tasks (Default: false)

Setting this flag to “true” enables the use of custom tasks from within pipelines. This is an experimental feature and thus should still be considered an alpha feature.
enable-api-fields (Default: stable)

Setting this flag will determine which gated features are enabled. Acceptable values are “stable” or “alpha”.
results-from (Default: termination-message)

This feature is to use the container’s termination message to fetch results from. Set it to “sidecar-logs” to enable use of a results sidecar logs to extract results instead of termination message.
max-result-size (Default: 4096)

This feature is to configure the size of the task results if using sidecar-logs. The default value if 4096 and maximum value can be 1572863.
enable-provenance-in-status (Default: true)

This feature is to enable populating the provenance field in TaskRun and PipelineRun status. The provenance field contains metadata about resources used in the TaskRun/PipelineRun such as the source from where a remote Task/Pipeline definition was fetched. To disable populating this field, set this flag to “false”.
set-security-context (Default: false)

Setting this flag to “true” to set a security context for containers injected by Tekton that will allow TaskRun pods to run in namespaces with restricted pod security admission
keep-pod-on-cancel (Default: false)

Setting this flag to “true” will not delete the pod associated with cancelled taskrun.
enforce-nonfalsifiability (Default: none)

Setting this flag to “spire” to enable integration with SPIRE.
enable-param-enum (Default: false)

Setting this flag to “true” will enable params of type Enum
enable-step-actions (Default: false)

Setting this flag to “true” will enable specifying StepAction in a Step. A StepAction is the reusable and scriptable unit of work that is performed by a Step
enable-cel-in-whenexpression (Default: false)

Setting this flag to “true” will enable using CEL in when expressions.
trusted-resources-verification-no-match-policy (Default: ignore)

Trusted Resources is a feature which can be used to sign Tekton Resources and verify them. Details of design can be found at TEP–0091. This feature is under alpha version and support v1beta1 version of Task and Pipeline. To know more about this visit pipelines documentation

Metrics Properties

These fields have default values so even if user have not passed them in CR, operator will add them and override the values configure in pipelines.

metrics.pipelinerun.duration-type (Default: histogram)

Setting this flag will determine the duration type - gauge or histogram.
metrics.pipelinerun.level (Default: pipeline)

Setting this flag will determine the level of pipelinerun metrics.
metrics.taskrun.duration-type (Default: histogram)

Setting this flag will determine the duration type - gauge or histogram.
metrics.taskrun.level (Default: task)

Setting this flag will determine the level of taskrun metrics.
metrics.count.enable-reason (Default: false)

Setting this flag to “true” will include reason label on count metrics.

Optional Properties

This fields doesn’t have default values so will be considered only if user passes them. By default Operator won’t add this fields CR and won’t configure for pipelines.

The Default values for this fields are already set in pipelines are not set by Operator. If user passes some values then those will be set for the particular field.

default-timeout-minutes

default-timeout-minutes contains the default number of minutes to use for TaskRun and PipelineRun, if none is specified.

default-timeout-minutes: "60" # 60 minutes
default-service-account

default-service-account contains the default service account name to use for TaskRun and PipelineRun, if none is specified.

default-service-account: "default"
default-managed-by-label-value

default-managed-by-label-value contains the default value given to the “app.kubernetes.io/managed-by” label applied to all Pods created for TaskRuns. If a user’s requested TaskRun specifies another value for this label, the user’s request supersedes.

default-managed-by-label-value: "tekton-pipelines"
disable-inline-spec (Default: ``)

Inline specifications can be disabled for specific resources only. To achieve that, set the disable-inline-spec flag to a comma-separated list of the desired resources. Valid values are pipeline, pipelinerun and taskrun.
default-pod-template

default-pod-template contains the default pod template to use TaskRun and PipelineRun, if none is specified. If a pod template is specified, the default pod template is ignored.
default-cloud-events-sink

default-cloud-events-sink contains the default CloudEvents sink to be used for TaskRun and PipelineRun, when no sink is specified. Note that right now it is still not possible to set a PipelineRun or TaskRun specific sink, so the default is the only option available. If no sink is specified, no CloudEvent is generated
default-task-run-workspace-binding

default-task-run-workspace-binding contains the default workspace configuration provided for any Workspaces that a Task declares but that a TaskRun does not explicitly provide.
default-resolver-type

default-resolver-type contains the resolver type to be used as default resolver.

Performance Properties

spec:
  # omitted other fields ...
  performance:
    disable-ha: false
    buckets: 1
    replicas: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10
    statefulset-ordinals: false

A high level descriptions are given here. To get the detailed information please visit pipelines documentation, High Availability Support, and Performance Configuration

disable-ha - enable or disable ha feature, defaults in pipelines controller is disable-ha=false
buckets - buckets is the number of buckets used to partition key space of each reconciler. If this number is M and the replica number of the controller is N, the N replicas will compete for the M buckets. The owner of a bucket will take care of the reconciling for the keys partitioned into that bucket. The maximum value of buckets at this time is 10. default value in pipeline controller is 1
replicas - pipelines controller deployment replicas count
threads-per-controller - is the number of threads(aka worker) to use when processing the pipelines controller’s workqueue, default value in pipelines controller is 2
kube-api-qps - QPS indicates the maximum QPS to the cluster master from the REST client, default value in pipeline controller is 5.0
kube-api-burst - maximum burst for throttle, default value in pipeline controller is 10
statefulset-ordinals - enables StatefulSet Ordinals mode for the Tekton Pipelines Controller. When set to true, the Pipelines Controller is deployed as a StatefulSet, allowing for multiple replicas to be configured with a load-balancing mode. This ensures that the load is evenly distributed across replicas, and the number of buckets is enforced to match the number of replicas. Moreover, There are two mechanisms available for scaling for scaling Pipelines Controller horizontally:

Using leader election, which allows for failover, but can result in hot-spotting.
Using StatefulSet ordinals, which doesn’t allow for failover, but guarantees load is evenly spread across replicas.

Note:

kube-api-qps and kube-api-burst will be multiplied by 2 in pipelines controller. To get the detailed information visit Performance Configuration guide

if you modify or remove any of the performance properties, tekton-pipelines-controller deployment and config-leader-election config-map (if buckets changed) will be updated, and tekton-pipelines-controller pods will be recreated

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Pipeline

TektonPipeline custom resource allows user to install and manage Tekton Pipeline.

It is recommended to install the component through TektonConfig.

The TektonPipeline CR is as below:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonPipeline
metadata:
  name: pipeline
spec:
  targetNamespace: tekton-pipelines
  await-sidecar-readiness: true
  coschedule: workspaces
  disable-affinity-assistant: false
  disable-creds-init: false
  disable-home-env-overwrite: true
  disable-working-directory-overwrite: true
  disable-inline-spec: "taskrun,pipelinerun,pipeline"
  enable-api-fields: beta
  enable-bundles-resolver: true
  enable-cel-in-whenexpression: false
  enable-cluster-resolver: true
  enable-custom-tasks: true
  enable-git-resolver: true
  enable-hub-resolver: true
  enable-param-enum: false
  enable-provenance-in-status: true
  enable-step-actions: false
  enforce-nonfalsifiability: none
  keep-pod-on-cancel: false
  max-result-size: 4096
  metrics.count.enable-reason: false
  metrics.pipelinerun.duration-type: histogram
  metrics.pipelinerun.level: pipeline
  metrics.taskrun.duration-type: histogram
  metrics.taskrun.level: task
  require-git-ssh-secret-known-hosts: false
  results-from: termination-message
  running-in-environment-with-injected-sidecars: true
  send-cloudevents-for-runs: false
  set-security-context: false
  trusted-resources-verification-no-match-policy: ignore
  performance:
    disable-ha: false
    buckets: 1
    replicas: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10
    statefulset-ordinals: false
  options:
    disabled: false
    configMaps: {}
    deployments: {}

You can install this component using TektonConfig by choosing appropriate profile.

Properties

This fields have default values so even if user have not passed them in CR, operator will add them. User can later change them as per their need.

disable-affinity-assistant (Default: false)

Setting this flag to “true” will prevent Tekton to create an Affinity Assistant for every TaskRun sharing a PVC workspace. The default behaviour is for Tekton to create Affinity Assistants.

See more in the workspace documentation about Affinity Assistant or more info here.
disable-creds-init (Default: false)

Setting this flag to “true” will prevent Tekton scanning attached service accounts and injecting any credentials it finds into your Steps.

The default behaviour currently is for Tekton to search service accounts for secrets matching a specified format and automatically mount those into your Steps.

Note: setting this to “true” will prevent PipelineResources from working. See more info here.
await-sidecar-readiness (Default: true)

Setting this flag to “false” to allow the Tekton controller to start a TasksRun’s first step immediately without waiting for sidecar containers to be running first.

Note: setting this flag to “false” will mean the running-in-environment-with-injected-sidecars flag has no effect.
coschedule (Default: workspaces)

This flag determines how PipelineRun Pods are scheduled with Affinity Assistant. Acceptable values are “workspaces” (default), “pipelineruns”, “isolate-pipelinerun”, or “disabled”
running-in-environment-with-injected-sidecars (Default: true)

This option should be set to false when Pipelines is running in a cluster that does not use injected sidecars such as Istio. Setting it to false should decrease the time it takes for a TaskRun to start running. For clusters that use injected sidecars, setting this option to false can lead to unexpected behavior.

See more info here.
require-git-ssh-secret-known-hosts (Default: false)

Setting this flag to “true” will require that any Git SSH Secret offered to Tekton must have known_hosts included.

See more info here.
enable-custom-tasks (Default: false)

Setting this flag to “true” enables the use of custom tasks from within pipelines. This is an experimental feature and thus should still be considered an alpha feature.
enable-api-fields (Default: stable)

Setting this flag will determine which gated features are enabled. Acceptable values are “stable” or “alpha”.
results-from (Default: termination-message)

This feature is to use the container’s termination message to fetch results from. Set it to “sidecar-logs” to enable use of a results sidecar logs to extract results instead of termination message.
max-result-size (Default: 4096)

This feature is to configure the size of the task results if using sidecar-logs. The default value if 4096 and maximum value can be 1572863.
enable-provenance-in-status (Default: true)

This feature is to enable populating the provenance field in TaskRun and PipelineRun status. The provenance field contains metadata about resources used in the TaskRun/PipelineRun such as the source from where a remote Task/Pipeline definition was fetched. To disable populating this field, set this flag to “false”.
set-security-context (Default: false)

Setting this flag to “true” to set a security context for containers injected by Tekton that will allow TaskRun pods to run in namespaces with restricted pod security admission
keep-pod-on-cancel (Default: false)

Setting this flag to “true” will not delete the pod associated with cancelled taskrun.
enforce-nonfalsifiability (Default: none)

Setting this flag to “spire” to enable integration with SPIRE.
enable-param-enum (Default: false)

Setting this flag to “true” will enable params of type Enum
enable-step-actions (Default: false)

Setting this flag to “true” will enable specifying StepAction in a Step. A StepAction is the reusable and scriptable unit of work that is performed by a Step
enable-cel-in-whenexpression (Default: false)

Setting this flag to “true” will enable using CEL in when expressions.
trusted-resources-verification-no-match-policy (Default: ignore)

Trusted Resources is a feature which can be used to sign Tekton Resources and verify them. Details of design can be found at TEP–0091. This feature is under alpha version and support v1beta1 version of Task and Pipeline. To know more about this visit pipelines documentation

Metrics Properties

These fields have default values so even if user have not passed them in CR, operator will add them and override the values configure in pipelines.

metrics.pipelinerun.duration-type (Default: histogram)

Setting this flag will determine the duration type - gauge or histogram.
metrics.pipelinerun.level (Default: pipeline)

Setting this flag will determine the level of pipelinerun metrics.
metrics.taskrun.duration-type (Default: histogram)

Setting this flag will determine the duration type - gauge or histogram.
metrics.taskrun.level (Default: task)

Setting this flag will determine the level of taskrun metrics.
metrics.count.enable-reason (Default: false)

Setting this flag to “true” will include reason label on count metrics.

Optional Properties

This fields doesn’t have default values so will be considered only if user passes them. By default Operator won’t add this fields CR and won’t configure for pipelines.

The Default values for this fields are already set in pipelines are not set by Operator. If user passes some values then those will be set for the particular field.

default-timeout-minutes

default-timeout-minutes contains the default number of minutes to use for TaskRun and PipelineRun, if none is specified.

default-timeout-minutes: "60" # 60 minutes
default-service-account

default-service-account contains the default service account name to use for TaskRun and PipelineRun, if none is specified.

default-service-account: "default"
default-managed-by-label-value

default-managed-by-label-value contains the default value given to the “app.kubernetes.io/managed-by” label applied to all Pods created for TaskRuns. If a user’s requested TaskRun specifies another value for this label, the user’s request supersedes.

default-managed-by-label-value: "tekton-pipelines"
disable-inline-spec (Default: ``)

Inline specifications can be disabled for specific resources only. To achieve that, set the disable-inline-spec flag to a comma-separated list of the desired resources. Valid values are pipeline, pipelinerun and taskrun.
default-pod-template

default-pod-template contains the default pod template to use TaskRun and PipelineRun, if none is specified. If a pod template is specified, the default pod template is ignored.
default-cloud-events-sink

default-cloud-events-sink contains the default CloudEvents sink to be used for TaskRun and PipelineRun, when no sink is specified. Note that right now it is still not possible to set a PipelineRun or TaskRun specific sink, so the default is the only option available. If no sink is specified, no CloudEvent is generated
default-task-run-workspace-binding

default-task-run-workspace-binding contains the default workspace configuration provided for any Workspaces that a Task declares but that a TaskRun does not explicitly provide.
default-resolver-type

default-resolver-type contains the resolver type to be used as default resolver.

Performance Properties

spec:
  # omitted other fields ...
  performance:
    disable-ha: false
    buckets: 1
    replicas: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10
    statefulset-ordinals: false

A high level descriptions are given here. To get the detailed information please visit pipelines documentation, High Availability Support, and Performance Configuration

disable-ha - enable or disable ha feature, defaults in pipelines controller is disable-ha=false
buckets - buckets is the number of buckets used to partition key space of each reconciler. If this number is M and the replica number of the controller is N, the N replicas will compete for the M buckets. The owner of a bucket will take care of the reconciling for the keys partitioned into that bucket. The maximum value of buckets at this time is 10. default value in pipeline controller is 1
replicas - pipelines controller deployment replicas count
threads-per-controller - is the number of threads(aka worker) to use when processing the pipelines controller’s workqueue, default value in pipelines controller is 2
kube-api-qps - QPS indicates the maximum QPS to the cluster master from the REST client, default value in pipeline controller is 5.0
kube-api-burst - maximum burst for throttle, default value in pipeline controller is 10
statefulset-ordinals - enables StatefulSet Ordinals mode for the Tekton Pipelines Controller. When set to true, the Pipelines Controller is deployed as a StatefulSet, allowing for multiple replicas to be configured with a load-balancing mode. This ensures that the load is evenly distributed across replicas, and the number of buckets is enforced to match the number of replicas. Moreover, There are two mechanisms available for scaling for scaling Pipelines Controller horizontally:

Using leader election, which allows for failover, but can result in hot-spotting.
Using StatefulSet ordinals, which doesn’t allow for failover, but guarantees load is evenly spread across replicas.

Note:

kube-api-qps and kube-api-burst will be multiplied by 2 in pipelines controller. To get the detailed information visit Performance Configuration guide

if you modify or remove any of the performance properties, tekton-pipelines-controller deployment and config-leader-election config-map (if buckets changed) will be updated, and tekton-pipelines-controller pods will be recreated

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Pipeline

TektonPipeline custom resource allows user to install and manage Tekton Pipeline.

It is recommended to install the component through TektonConfig.

The TektonPipeline CR is as below:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonPipeline
metadata:
  name: pipeline
spec:
  targetNamespace: tekton-pipelines
  await-sidecar-readiness: true
  coschedule: workspaces
  disable-affinity-assistant: false
  disable-creds-init: false
  disable-home-env-overwrite: true
  disable-working-directory-overwrite: true
  disable-inline-spec: "taskrun,pipelinerun,pipeline"
  enable-api-fields: beta
  enable-bundles-resolver: true
  enable-cel-in-whenexpression: false
  enable-cluster-resolver: true
  enable-custom-tasks: true
  enable-git-resolver: true
  enable-hub-resolver: true
  enable-param-enum: false
  enable-provenance-in-status: true
  enable-step-actions: false
  enforce-nonfalsifiability: none
  keep-pod-on-cancel: false
  max-result-size: 4096
  metrics.count.enable-reason: false
  metrics.pipelinerun.duration-type: histogram
  metrics.pipelinerun.level: pipeline
  metrics.taskrun.duration-type: histogram
  metrics.taskrun.level: task
  require-git-ssh-secret-known-hosts: false
  results-from: termination-message
  running-in-environment-with-injected-sidecars: true
  send-cloudevents-for-runs: false
  set-security-context: false
  trusted-resources-verification-no-match-policy: ignore
  performance:
    disable-ha: false
    buckets: 1
    replicas: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10
    statefulset-ordinals: false
  options:
    disabled: false
    configMaps: {}
    deployments: {}

You can install this component using TektonConfig by choosing appropriate profile.

Properties

This fields have default values so even if user have not passed them in CR, operator will add them. User can later change them as per their need.

disable-affinity-assistant (Default: false)

Setting this flag to “true” will prevent Tekton to create an Affinity Assistant for every TaskRun sharing a PVC workspace. The default behaviour is for Tekton to create Affinity Assistants.

See more in the workspace documentation about Affinity Assistant or more info here.
disable-creds-init (Default: false)

Setting this flag to “true” will prevent Tekton scanning attached service accounts and injecting any credentials it finds into your Steps.

The default behaviour currently is for Tekton to search service accounts for secrets matching a specified format and automatically mount those into your Steps.

Note: setting this to “true” will prevent PipelineResources from working. See more info here.
await-sidecar-readiness (Default: true)

Setting this flag to “false” to allow the Tekton controller to start a TasksRun’s first step immediately without waiting for sidecar containers to be running first.

Note: setting this flag to “false” will mean the running-in-environment-with-injected-sidecars flag has no effect.
coschedule (Default: workspaces)

This flag determines how PipelineRun Pods are scheduled with Affinity Assistant. Acceptable values are “workspaces” (default), “pipelineruns”, “isolate-pipelinerun”, or “disabled”
running-in-environment-with-injected-sidecars (Default: true)

This option should be set to false when Pipelines is running in a cluster that does not use injected sidecars such as Istio. Setting it to false should decrease the time it takes for a TaskRun to start running. For clusters that use injected sidecars, setting this option to false can lead to unexpected behavior.

See more info here.
require-git-ssh-secret-known-hosts (Default: false)

Setting this flag to “true” will require that any Git SSH Secret offered to Tekton must have known_hosts included.

See more info here.
enable-custom-tasks (Default: false)

Setting this flag to “true” enables the use of custom tasks from within pipelines. This is an experimental feature and thus should still be considered an alpha feature.
enable-api-fields (Default: stable)

Setting this flag will determine which gated features are enabled. Acceptable values are “stable” or “alpha”.
results-from (Default: termination-message)

This feature is to use the container’s termination message to fetch results from. Set it to “sidecar-logs” to enable use of a results sidecar logs to extract results instead of termination message.
max-result-size (Default: 4096)

This feature is to configure the size of the task results if using sidecar-logs. The default value if 4096 and maximum value can be 1572863.
enable-provenance-in-status (Default: true)

This feature is to enable populating the provenance field in TaskRun and PipelineRun status. The provenance field contains metadata about resources used in the TaskRun/PipelineRun such as the source from where a remote Task/Pipeline definition was fetched. To disable populating this field, set this flag to “false”.
set-security-context (Default: false)

Setting this flag to “true” to set a security context for containers injected by Tekton that will allow TaskRun pods to run in namespaces with restricted pod security admission
keep-pod-on-cancel (Default: false)

Setting this flag to “true” will not delete the pod associated with cancelled taskrun.
enforce-nonfalsifiability (Default: none)

Setting this flag to “spire” to enable integration with SPIRE.
enable-param-enum (Default: false)

Setting this flag to “true” will enable params of type Enum
enable-step-actions (Default: false)

Setting this flag to “true” will enable specifying StepAction in a Step. A StepAction is the reusable and scriptable unit of work that is performed by a Step
enable-cel-in-whenexpression (Default: false)

Setting this flag to “true” will enable using CEL in when expressions.
trusted-resources-verification-no-match-policy (Default: ignore)

Trusted Resources is a feature which can be used to sign Tekton Resources and verify them. Details of design can be found at TEP–0091. This feature is under alpha version and support v1beta1 version of Task and Pipeline. To know more about this visit pipelines documentation

Metrics Properties

These fields have default values so even if user have not passed them in CR, operator will add them and override the values configure in pipelines.

metrics.pipelinerun.duration-type (Default: histogram)

Setting this flag will determine the duration type - gauge or histogram.
metrics.pipelinerun.level (Default: pipeline)

Setting this flag will determine the level of pipelinerun metrics.
metrics.taskrun.duration-type (Default: histogram)

Setting this flag will determine the duration type - gauge or histogram.
metrics.taskrun.level (Default: task)

Setting this flag will determine the level of taskrun metrics.
metrics.count.enable-reason (Default: false)

Setting this flag to “true” will include reason label on count metrics.

Optional Properties

This fields doesn’t have default values so will be considered only if user passes them. By default Operator won’t add this fields CR and won’t configure for pipelines.

The Default values for this fields are already set in pipelines are not set by Operator. If user passes some values then those will be set for the particular field.

default-timeout-minutes

default-timeout-minutes contains the default number of minutes to use for TaskRun and PipelineRun, if none is specified.

default-timeout-minutes: "60" # 60 minutes
default-service-account

default-service-account contains the default service account name to use for TaskRun and PipelineRun, if none is specified.

default-service-account: "default"
default-managed-by-label-value

default-managed-by-label-value contains the default value given to the “app.kubernetes.io/managed-by” label applied to all Pods created for TaskRuns. If a user’s requested TaskRun specifies another value for this label, the user’s request supersedes.

default-managed-by-label-value: "tekton-pipelines"
disable-inline-spec (Default: ``)

Inline specifications can be disabled for specific resources only. To achieve that, set the disable-inline-spec flag to a comma-separated list of the desired resources. Valid values are pipeline, pipelinerun and taskrun.
default-pod-template

default-pod-template contains the default pod template to use TaskRun and PipelineRun, if none is specified. If a pod template is specified, the default pod template is ignored.
default-cloud-events-sink

default-cloud-events-sink contains the default CloudEvents sink to be used for TaskRun and PipelineRun, when no sink is specified. Note that right now it is still not possible to set a PipelineRun or TaskRun specific sink, so the default is the only option available. If no sink is specified, no CloudEvent is generated
default-task-run-workspace-binding

default-task-run-workspace-binding contains the default workspace configuration provided for any Workspaces that a Task declares but that a TaskRun does not explicitly provide.
default-resolver-type

default-resolver-type contains the resolver type to be used as default resolver.

Performance Properties

spec:
  # omitted other fields ...
  performance:
    disable-ha: false
    buckets: 1
    replicas: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10
    statefulset-ordinals: false

A high level descriptions are given here. To get the detailed information please visit pipelines documentation, High Availability Support, and Performance Configuration

disable-ha - enable or disable ha feature, defaults in pipelines controller is disable-ha=false
buckets - buckets is the number of buckets used to partition key space of each reconciler. If this number is M and the replica number of the controller is N, the N replicas will compete for the M buckets. The owner of a bucket will take care of the reconciling for the keys partitioned into that bucket. The maximum value of buckets at this time is 10. default value in pipeline controller is 1
replicas - pipelines controller deployment replicas count
threads-per-controller - is the number of threads(aka worker) to use when processing the pipelines controller’s workqueue, default value in pipelines controller is 2
kube-api-qps - QPS indicates the maximum QPS to the cluster master from the REST client, default value in pipeline controller is 5.0
kube-api-burst - maximum burst for throttle, default value in pipeline controller is 10
statefulset-ordinals - enables StatefulSet Ordinals mode for the Tekton Pipelines Controller. When set to true, the Pipelines Controller is deployed as a StatefulSet, allowing for multiple replicas to be configured with a load-balancing mode. This ensures that the load is evenly distributed across replicas, and the number of buckets is enforced to match the number of replicas. Moreover, There are two mechanisms available for scaling for scaling Pipelines Controller horizontally:

Using leader election, which allows for failover, but can result in hot-spotting.
Using StatefulSet ordinals, which doesn’t allow for failover, but guarantees load is evenly spread across replicas.

Note:

kube-api-qps and kube-api-burst will be multiplied by 2 in pipelines controller. To get the detailed information visit Performance Configuration guide

if you modify or remove any of the performance properties, tekton-pipelines-controller deployment and config-leader-election config-map (if buckets changed) will be updated, and tekton-pipelines-controller pods will be recreated

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Pipeline

TektonPipeline custom resource allows user to install and manage Tekton Pipeline.

It is recommended to install the component through TektonConfig.

The TektonPipeline CR is as below:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonPipeline
metadata:
  name: pipeline
spec:
  targetNamespace: tekton-pipelines
  await-sidecar-readiness: true
  coschedule: workspaces
  disable-affinity-assistant: false
  disable-creds-init: false
  disable-home-env-overwrite: true
  disable-working-directory-overwrite: true
  disable-inline-spec: "taskrun,pipelinerun,pipeline"
  enable-api-fields: beta
  enable-bundles-resolver: true
  enable-cel-in-whenexpression: false
  enable-cluster-resolver: true
  enable-custom-tasks: true
  enable-git-resolver: true
  enable-hub-resolver: true
  enable-param-enum: false
  enable-provenance-in-status: true
  enable-step-actions: false
  enforce-nonfalsifiability: none
  keep-pod-on-cancel: false
  max-result-size: 4096
  metrics.count.enable-reason: false
  metrics.pipelinerun.duration-type: histogram
  metrics.pipelinerun.level: pipeline
  metrics.taskrun.duration-type: histogram
  metrics.taskrun.level: task
  require-git-ssh-secret-known-hosts: false
  results-from: termination-message
  running-in-environment-with-injected-sidecars: true
  send-cloudevents-for-runs: false
  set-security-context: false
  trusted-resources-verification-no-match-policy: ignore
  performance:
    disable-ha: false
    buckets: 1
    replicas: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10
    statefulset-ordinals: false
  options:
    disabled: false
    configMaps: {}
    deployments: {}

You can install this component using TektonConfig by choosing appropriate profile.

Properties

This fields have default values so even if user have not passed them in CR, operator will add them. User can later change them as per their need.

disable-affinity-assistant (Default: false)

Setting this flag to “true” will prevent Tekton to create an Affinity Assistant for every TaskRun sharing a PVC workspace. The default behaviour is for Tekton to create Affinity Assistants.

See more in the workspace documentation about Affinity Assistant or more info here.
disable-creds-init (Default: false)

Setting this flag to “true” will prevent Tekton scanning attached service accounts and injecting any credentials it finds into your Steps.

The default behaviour currently is for Tekton to search service accounts for secrets matching a specified format and automatically mount those into your Steps.

Note: setting this to “true” will prevent PipelineResources from working. See more info here.
await-sidecar-readiness (Default: true)

Setting this flag to “false” to allow the Tekton controller to start a TasksRun’s first step immediately without waiting for sidecar containers to be running first.

Note: setting this flag to “false” will mean the running-in-environment-with-injected-sidecars flag has no effect.
coschedule (Default: workspaces)

This flag determines how PipelineRun Pods are scheduled with Affinity Assistant. Acceptable values are “workspaces” (default), “pipelineruns”, “isolate-pipelinerun”, or “disabled”
running-in-environment-with-injected-sidecars (Default: true)

This option should be set to false when Pipelines is running in a cluster that does not use injected sidecars such as Istio. Setting it to false should decrease the time it takes for a TaskRun to start running. For clusters that use injected sidecars, setting this option to false can lead to unexpected behavior.

See more info here.
require-git-ssh-secret-known-hosts (Default: false)

Setting this flag to “true” will require that any Git SSH Secret offered to Tekton must have known_hosts included.

See more info here.
enable-custom-tasks (Default: false)

Setting this flag to “true” enables the use of custom tasks from within pipelines. This is an experimental feature and thus should still be considered an alpha feature.
enable-api-fields (Default: stable)

Setting this flag will determine which gated features are enabled. Acceptable values are “stable” or “alpha”.
results-from (Default: termination-message)

This feature is to use the container’s termination message to fetch results from. Set it to “sidecar-logs” to enable use of a results sidecar logs to extract results instead of termination message.
max-result-size (Default: 4096)

This feature is to configure the size of the task results if using sidecar-logs. The default value if 4096 and maximum value can be 1572863.
enable-provenance-in-status (Default: true)

This feature is to enable populating the provenance field in TaskRun and PipelineRun status. The provenance field contains metadata about resources used in the TaskRun/PipelineRun such as the source from where a remote Task/Pipeline definition was fetched. To disable populating this field, set this flag to “false”.
set-security-context (Default: false)

Setting this flag to “true” to set a security context for containers injected by Tekton that will allow TaskRun pods to run in namespaces with restricted pod security admission
keep-pod-on-cancel (Default: false)

Setting this flag to “true” will not delete the pod associated with cancelled taskrun.
enforce-nonfalsifiability (Default: none)

Setting this flag to “spire” to enable integration with SPIRE.
enable-param-enum (Default: false)

Setting this flag to “true” will enable params of type Enum
enable-step-actions (Default: false)

Setting this flag to “true” will enable specifying StepAction in a Step. A StepAction is the reusable and scriptable unit of work that is performed by a Step
enable-cel-in-whenexpression (Default: false)

Setting this flag to “true” will enable using CEL in when expressions.
trusted-resources-verification-no-match-policy (Default: ignore)

Trusted Resources is a feature which can be used to sign Tekton Resources and verify them. Details of design can be found at TEP–0091. This feature is under alpha version and support v1beta1 version of Task and Pipeline. To know more about this visit pipelines documentation

Metrics Properties

These fields have default values so even if user have not passed them in CR, operator will add them and override the values configure in pipelines.

metrics.pipelinerun.duration-type (Default: histogram)

Setting this flag will determine the duration type - gauge or histogram.
metrics.pipelinerun.level (Default: pipeline)

Setting this flag will determine the level of pipelinerun metrics.
metrics.taskrun.duration-type (Default: histogram)

Setting this flag will determine the duration type - gauge or histogram.
metrics.taskrun.level (Default: task)

Setting this flag will determine the level of taskrun metrics.
metrics.count.enable-reason (Default: false)

Setting this flag to “true” will include reason label on count metrics.

Optional Properties

This fields doesn’t have default values so will be considered only if user passes them. By default Operator won’t add this fields CR and won’t configure for pipelines.

The Default values for this fields are already set in pipelines are not set by Operator. If user passes some values then those will be set for the particular field.

default-timeout-minutes

default-timeout-minutes contains the default number of minutes to use for TaskRun and PipelineRun, if none is specified.

default-timeout-minutes: "60" # 60 minutes
default-service-account

default-service-account contains the default service account name to use for TaskRun and PipelineRun, if none is specified.

default-service-account: "default"
default-managed-by-label-value

default-managed-by-label-value contains the default value given to the “app.kubernetes.io/managed-by” label applied to all Pods created for TaskRuns. If a user’s requested TaskRun specifies another value for this label, the user’s request supersedes.

default-managed-by-label-value: "tekton-pipelines"
disable-inline-spec (Default: ``)

Inline specifications can be disabled for specific resources only. To achieve that, set the disable-inline-spec flag to a comma-separated list of the desired resources. Valid values are pipeline, pipelinerun and taskrun.
default-pod-template

default-pod-template contains the default pod template to use TaskRun and PipelineRun, if none is specified. If a pod template is specified, the default pod template is ignored.
default-cloud-events-sink

default-cloud-events-sink contains the default CloudEvents sink to be used for TaskRun and PipelineRun, when no sink is specified. Note that right now it is still not possible to set a PipelineRun or TaskRun specific sink, so the default is the only option available. If no sink is specified, no CloudEvent is generated
default-task-run-workspace-binding

default-task-run-workspace-binding contains the default workspace configuration provided for any Workspaces that a Task declares but that a TaskRun does not explicitly provide.
default-resolver-type

default-resolver-type contains the resolver type to be used as default resolver.

Performance Properties

spec:
  # omitted other fields ...
  performance:
    disable-ha: false
    buckets: 1
    replicas: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10
    statefulset-ordinals: false

A high level descriptions are given here. To get the detailed information please visit pipelines documentation, High Availability Support, and Performance Configuration

disable-ha - enable or disable ha feature, defaults in pipelines controller is disable-ha=false
buckets - buckets is the number of buckets used to partition key space of each reconciler. If this number is M and the replica number of the controller is N, the N replicas will compete for the M buckets. The owner of a bucket will take care of the reconciling for the keys partitioned into that bucket. The maximum value of buckets at this time is 10. default value in pipeline controller is 1
replicas - pipelines controller deployment replicas count
threads-per-controller - is the number of threads(aka worker) to use when processing the pipelines controller’s workqueue, default value in pipelines controller is 2
kube-api-qps - QPS indicates the maximum QPS to the cluster master from the REST client, default value in pipeline controller is 5.0
kube-api-burst - maximum burst for throttle, default value in pipeline controller is 10
statefulset-ordinals - enables StatefulSet Ordinals mode for the Tekton Pipelines Controller. When set to true, the Pipelines Controller is deployed as a StatefulSet, allowing for multiple replicas to be configured with a load-balancing mode. This ensures that the load is evenly distributed across replicas, and the number of buckets is enforced to match the number of replicas. Moreover, There are two mechanisms available for scaling for scaling Pipelines Controller horizontally:

Using leader election, which allows for failover, but can result in hot-spotting.
Using StatefulSet ordinals, which doesn’t allow for failover, but guarantees load is evenly spread across replicas.

Note:

kube-api-qps and kube-api-burst will be multiplied by 2 in pipelines controller. To get the detailed information visit Performance Configuration guide

if you modify or remove any of the performance properties, tekton-pipelines-controller deployment and config-leader-election config-map (if buckets changed) will be updated, and tekton-pipelines-controller pods will be recreated

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Pipeline

TektonPipeline custom resource allows user to install and manage Tekton Pipeline.

It is recommended to install the component through TektonConfig.

The TektonPipeline CR is as below:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonPipeline
metadata:
  name: pipeline
spec:
  targetNamespace: tekton-pipelines
  await-sidecar-readiness: true
  coschedule: workspaces
  disable-affinity-assistant: false
  disable-creds-init: false
  disable-home-env-overwrite: true
  disable-working-directory-overwrite: true
  disable-inline-spec: "taskrun,pipelinerun,pipeline"
  enable-api-fields: beta
  enable-bundles-resolver: true
  enable-cel-in-whenexpression: false
  enable-cluster-resolver: true
  enable-custom-tasks: true
  enable-git-resolver: true
  enable-hub-resolver: true
  enable-param-enum: false
  enable-provenance-in-status: true
  enable-step-actions: false
  enforce-nonfalsifiability: none
  keep-pod-on-cancel: false
  max-result-size: 4096
  metrics.count.enable-reason: false
  metrics.pipelinerun.duration-type: histogram
  metrics.pipelinerun.level: pipeline
  metrics.taskrun.duration-type: histogram
  metrics.taskrun.level: task
  # Tracing configuration (optional)
  # traces.enabled: true
  # traces.endpoint: "http://jaeger-collector.jaeger.svc.cluster.local:4318/v1/traces"
  # traces.credentialsSecret: ""
  require-git-ssh-secret-known-hosts: false
  results-from: termination-message
  running-in-environment-with-injected-sidecars: true
  send-cloudevents-for-runs: false
  set-security-context: false
  trusted-resources-verification-no-match-policy: ignore
  performance:
    disable-ha: false
    buckets: 1
    replicas: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10
    statefulset-ordinals: false
  options:
    disabled: false
    configMaps: {}
    deployments: {}

You can install this component using TektonConfig by choosing appropriate profile.

Properties

This fields have default values so even if user have not passed them in CR, operator will add them. User can later change them as per their need.

disable-affinity-assistant (Default: false)

Setting this flag to “true” will prevent Tekton to create an Affinity Assistant for every TaskRun sharing a PVC workspace. The default behaviour is for Tekton to create Affinity Assistants.

See more in the workspace documentation about Affinity Assistant or more info here.
disable-creds-init (Default: false)

Setting this flag to “true” will prevent Tekton scanning attached service accounts and injecting any credentials it finds into your Steps.

The default behaviour currently is for Tekton to search service accounts for secrets matching a specified format and automatically mount those into your Steps.

Note: setting this to “true” will prevent PipelineResources from working. See more info here.
await-sidecar-readiness (Default: true)

Setting this flag to “false” to allow the Tekton controller to start a TasksRun’s first step immediately without waiting for sidecar containers to be running first.

Note: setting this flag to “false” will mean the running-in-environment-with-injected-sidecars flag has no effect.
coschedule (Default: workspaces)

This flag determines how PipelineRun Pods are scheduled with Affinity Assistant. Acceptable values are “workspaces” (default), “pipelineruns”, “isolate-pipelinerun”, or “disabled”
running-in-environment-with-injected-sidecars (Default: true)

This option should be set to false when Pipelines is running in a cluster that does not use injected sidecars such as Istio. Setting it to false should decrease the time it takes for a TaskRun to start running. For clusters that use injected sidecars, setting this option to false can lead to unexpected behavior.

See more info here.
require-git-ssh-secret-known-hosts (Default: false)

Setting this flag to “true” will require that any Git SSH Secret offered to Tekton must have known_hosts included.

See more info here.
enable-custom-tasks (Default: false)

Setting this flag to “true” enables the use of custom tasks from within pipelines. This is an experimental feature and thus should still be considered an alpha feature.
enable-api-fields (Default: stable)

Setting this flag will determine which gated features are enabled. Acceptable values are “stable” or “alpha”.
results-from (Default: termination-message)

This feature is to use the container’s termination message to fetch results from. Set it to “sidecar-logs” to enable use of a results sidecar logs to extract results instead of termination message.
max-result-size (Default: 4096)

This feature is to configure the size of the task results if using sidecar-logs. The default value if 4096 and maximum value can be 1572863.
enable-provenance-in-status (Default: true)

This feature is to enable populating the provenance field in TaskRun and PipelineRun status. The provenance field contains metadata about resources used in the TaskRun/PipelineRun such as the source from where a remote Task/Pipeline definition was fetched. To disable populating this field, set this flag to “false”.
set-security-context (Default: false)

Setting this flag to “true” to set a security context for containers injected by Tekton that will allow TaskRun pods to run in namespaces with restricted pod security admission
keep-pod-on-cancel (Default: false)

Setting this flag to “true” will not delete the pod associated with cancelled taskrun.
enforce-nonfalsifiability (Default: none)

Setting this flag to “spire” to enable integration with SPIRE.
enable-param-enum (Default: false)

Setting this flag to “true” will enable params of type Enum
enable-step-actions (Default: false)

Setting this flag to “true” will enable specifying StepAction in a Step. A StepAction is the reusable and scriptable unit of work that is performed by a Step
enable-cel-in-whenexpression (Default: false)

Setting this flag to “true” will enable using CEL in when expressions.
trusted-resources-verification-no-match-policy (Default: ignore)

Trusted Resources is a feature which can be used to sign Tekton Resources and verify them. Details of design can be found at TEP–0091. This feature is under alpha version and support v1beta1 version of Task and Pipeline. To know more about this visit pipelines documentation

Metrics Properties

These fields have default values so even if user have not passed them in CR, operator will add them and override the values configure in pipelines.

metrics.pipelinerun.duration-type (Default: histogram)

Setting this flag will determine the duration type - gauge or histogram.
metrics.pipelinerun.level (Default: pipeline)

Setting this flag will determine the level of pipelinerun metrics.
metrics.taskrun.duration-type (Default: histogram)

Setting this flag will determine the duration type - gauge or histogram.
metrics.taskrun.level (Default: task)

Setting this flag will determine the level of taskrun metrics.
metrics.count.enable-reason (Default: false)

Setting this flag to “true” will include reason label on count metrics.

Tracing Properties

traces.enabled (Optional)

Setting this flag to “true” enables distributed tracing for Tekton Pipelines. When enabled, the pipeline controller will export trace spans for pipeline and task reconciliation operations.
```
spec:
  traces.enabled: true
```
traces.endpoint (Optional)

The URL of the OpenTelemetry trace collector endpoint. Tekton Pipeline exports traces using the OTLP (OpenTelemetry Protocol) format over HTTP.

Supported endpoints:
- Jaeger with OTLP: Use port 4318 for OTLP HTTP (e.g., http://jaeger-collector.jaeger.svc.cluster.local:4318/v1/traces)
- OpenTelemetry Collector: OTLP HTTP endpoint (e.g., http://otel-collector.observability.svc.cluster.local:4318/v1/traces)
- Other OTLP-compatible backends: Any trace backend that supports OTLP HTTP protocol
```
spec:
  traces.enabled: true
  traces.endpoint: "http://jaeger-collector.jaeger.svc.cluster.local:4318/v1/traces"
```
traces.credentialsSecret (Optional)

The name of a Kubernetes secret containing credentials for authenticating with the tracing endpoint. This is useful when your tracing backend requires authentication.
```
spec:
  traces.enabled: true
  traces.endpoint: "https://secure-jaeger-collector.example.com/api/traces"
  traces.credentialsSecret: "jaeger-auth-secret"
```

Example: Complete Tracing Configuration

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonPipeline
metadata:
  name: pipeline
spec:
  targetNamespace: tekton-pipelines
  # ... other configuration ...

  # Enable tracing with OpenTelemetry Collector
  traces.enabled: true
  traces.endpoint: "http://otel-collector.observability.svc.cluster.local:4318/v1/traces"

Example: Tracing with Jaeger

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonPipeline
metadata:
  name: pipeline
spec:
  targetNamespace: tekton-pipelines
  # ... other configuration ...

  # Enable tracing with Jaeger (using OTLP endpoint)
  traces.enabled: true
  traces.endpoint: "http://jaeger-collector.jaeger.svc.cluster.local:4318/v1/traces"

For more information about distributed tracing in Tekton Pipelines, see the TEP-0124: Distributed Tracing for Tasks and Pipelines.

Optional Properties

This fields doesn’t have default values so will be considered only if user passes them. By default Operator won’t add this fields CR and won’t configure for pipelines.

The Default values for this fields are already set in pipelines are not set by Operator. If user passes some values then those will be set for the particular field.

default-timeout-minutes

default-timeout-minutes contains the default number of minutes to use for TaskRun and PipelineRun, if none is specified.

default-timeout-minutes: "60" # 60 minutes
default-service-account

default-service-account contains the default service account name to use for TaskRun and PipelineRun, if none is specified.

default-service-account: "default"
default-managed-by-label-value

default-managed-by-label-value contains the default value given to the “app.kubernetes.io/managed-by” label applied to all Pods created for TaskRuns. If a user’s requested TaskRun specifies another value for this label, the user’s request supersedes.

default-managed-by-label-value: "tekton-pipelines"
disable-inline-spec (Default: ``)

Inline specifications can be disabled for specific resources only. To achieve that, set the disable-inline-spec flag to a comma-separated list of the desired resources. Valid values are pipeline, pipelinerun and taskrun.
default-pod-template

default-pod-template contains the default pod template to use TaskRun and PipelineRun, if none is specified. If a pod template is specified, the default pod template is ignored.
default-cloud-events-sink

default-cloud-events-sink contains the default CloudEvents sink to be used for TaskRun and PipelineRun, when no sink is specified. Note that right now it is still not possible to set a PipelineRun or TaskRun specific sink, so the default is the only option available. If no sink is specified, no CloudEvent is generated
default-task-run-workspace-binding

default-task-run-workspace-binding contains the default workspace configuration provided for any Workspaces that a Task declares but that a TaskRun does not explicitly provide.
default-resolver-type

default-resolver-type contains the resolver type to be used as default resolver.

Performance Properties

spec:
  # omitted other fields ...
  performance:
    disable-ha: false
    buckets: 1
    replicas: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10
    statefulset-ordinals: false

A high level descriptions are given here. To get the detailed information please visit pipelines documentation, High Availability Support, and Performance Configuration

disable-ha - enable or disable ha feature, defaults in pipelines controller is disable-ha=false
buckets - buckets is the number of buckets used to partition key space of each reconciler. If this number is M and the replica number of the controller is N, the N replicas will compete for the M buckets. The owner of a bucket will take care of the reconciling for the keys partitioned into that bucket. The maximum value of buckets at this time is 10. default value in pipeline controller is 1
replicas - pipelines controller deployment replicas count
threads-per-controller - is the number of threads(aka worker) to use when processing the pipelines controller’s workqueue, default value in pipelines controller is 2
kube-api-qps - QPS indicates the maximum QPS to the cluster master from the REST client, default value in pipeline controller is 5.0
kube-api-burst - maximum burst for throttle, default value in pipeline controller is 10
statefulset-ordinals - enables StatefulSet Ordinals mode for the Tekton Pipelines Controller. When set to true, the Pipelines Controller is deployed as a StatefulSet, allowing for multiple replicas to be configured with a load-balancing mode. This ensures that the load is evenly distributed across replicas, and the number of buckets is enforced to match the number of replicas. Moreover, There are two mechanisms available for scaling for scaling Pipelines Controller horizontally:

Using leader election, which allows for failover, but can result in hot-spotting.
Using StatefulSet ordinals, which doesn’t allow for failover, but guarantees load is evenly spread across replicas.

Note:

kube-api-qps and kube-api-burst will be multiplied by 2 in pipelines controller. To get the detailed information visit Performance Configuration guide

if you modify or remove any of the performance properties, tekton-pipelines-controller deployment and config-leader-election config-map (if buckets changed) will be updated, and tekton-pipelines-controller pods will be recreated

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

`EventListeners`

An EventListener is a Kubernetes object that listens for events at a specified port on your Kubernetes cluster. It exposes an addressable sink that receives incoming event and specifies one or more Triggers. The sink is a Kubernetes service running the sink logic inside a dedicated Pod.

Each Trigger, in turn, allows you to specify one or more TriggerBindings that allow you to extract fields and their values from event payloads, and one or more TriggerTemplates that receive field values from the corresponding TriggerBindings and allow Tekton Triggers to instantiate resources such as TaskRuns and PipelineRuns with that data.

If you need to modify, filter, or validate the event payload data before passing it to a TriggerBinding, you can optionally specify one or more Interceptors.

Structure of an `EventListener`

An EventListener definition consists of the following fields:

Required:
- apiVersion - specifies the target API version, for example triggers.tekton.dev/v1alpha1
- kind - specifies that this Kubernetes resource is an EventListener object
- metadata - specifies data that uniquely identifies this EventListener object, for example a name
- spec - specifies the configuration of your EventListener:
  - serviceAccountName - Specifies the ServiceAccount the EventListener will use to instantiate Tekton resources
Optional:
- triggers - specifies a list of Triggers to execute upon event detection
- cloudEventURI - specifies the URI for cloudevent sink
- resources - specifies the resources that will be available to the event listening service
- namespaceSelector - specifies the namespace for the EventListener; this is where the EventListener looks for the specified Triggers and stores the Tekton objects it instantiates upon event detection
- labelSelector - specifies the labels for which your EventListener recognizes Triggers and instantiates the specified Tekton objects

See our Tekton Triggers examples for ready-to-use example EventListener definitions.

Specifying the Kubernetes service account

You must specify a Kubernetes service account in the serviceAccountName field that the EventListener will use to instantiate Tekton objects.

Tekton Trigger creates 2 clusterroles while installing with necessary permissions required for an eventlistener. You can directly create bindings for your serviceaccount with the clusterroles.

A Kubernetes RoleBinding with tekton-triggers-eventlistener-roles clusterrole.
A Kubernetes ClusterRoleBinding with tekton-triggers-eventlistener-clusterroles clusterrole.

You can checkout an example here.
If you’re using namespaceSelectors in your EventListener, you will have to create an additional ClusterRoleBinding with tekton-triggers-eventlistener-roles clusterrole.

Specifying `Triggers`

You can optionally specify one or more Triggers that define the actions to take when the EventListener detects a qualifying event. You can specify either a reference to an external Trigger object or reference/define the TriggerBindings, TriggerTemplates, and Interceptors in the Trigger definition. A Trigger definition specifies the following fields:

name - (optional) a valid Kubernetes name that uniquely identifies the Trigger
interceptors - (optional) a list of Interceptors that will process event payload data before passing it to the associated TriggerBinding
bindings - (optional) a list of TriggerBindings for this Trigger; you can either reference existing TriggerBindings or embed their definitions directly
template - (optional) a TriggerTemplate for this Trigger; you can either reference an existing TriggerTemplate or embed its definition directly
triggerRef - (optional) a reference to an external Trigger

Below is an example Trigger definition that references the desired TriggerBindings, TriggerTemplates, and Interceptors:

triggers:
  - name: trigger-1
    interceptors:
      - github:
          eventTypes: ["pull_request"]
    bindings:
      - ref: pipeline-binding # Reference to a TriggerBinding object
      - name: message # Embedded Binding
        value: Hello from the Triggers EventListener!
    template:
      ref: pipeline-template

Below is an example Trigger definition that specifies a reference to an external Trigger object:

triggers:
    - triggerRef: trigger

Below is an example Trigger definition that embeds a triggerTemplate definition directly:

triggers:
  - name: "my-trigger"
    template:
      spec:
        params:
          - name: "my-param-name"
        resourceTemplates:
        - apiVersion: "tekton.dev/v1beta1"
          kind: TaskRun
          metadata:
            generateName: "pr-run-"
          spec:
            taskSpec:
              steps:
              - image: ubuntu
                script: echo "hello there"

Below is an example Trigger definition tailored to a multi-tenant scenario in which you may not want all of your Trigger objects to have the same permissions as the EventListener. In such case, you can specify a different service account at the Trigger level. This service account overrides the service account specified in the EventListener.

triggers:
  - name: trigger-1
    serviceAccountName: trigger-1-sa
    interceptors:
      - github:
          eventTypes: ["pull_request"]
    bindings:
      - ref: pipeline-binding
      - ref: message-binding
    template:
      ref: pipeline-template

You must update the Role assigned to the service account specified in the EventListener as shown below to allow it to impersonate the service account specified in the Trigger:

rules:
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["impersonate"]

Specifying `cloudEventURI`

Specifying the URI for cloud event sink which receives cloud events during Trigger Processing.

spec:
  cloudEventURI: http://eventlistener.free.beeceptor.com

Specifying `TriggerGroups`

TriggerGroups is a feature that allows you to specify a set of interceptors that will process before a set of Trigger resources are processed by the eventlistener. The goal of this feature is described in TEP-0053. TriggerGroups allow for a common set of interceptors to be defined inline in the EventListenerSpec before Triggers are invoked.

A TriggerGroup definition specifies the following fields:

name - (optional) a valid Kubernetes name that uniquely identifies the TriggerGroup
interceptors - a list of Interceptors that will process event payload data before passing it to the downstream Triggers
triggerSelector - a combination of a Kubernetes labelSelector and a namespaceSelector as defined later in this document. These two fields work together to define the Triggers that will be processed once Interceptors processing completes.

Below is an example EventListener that defines an inline triggerGroup:

apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: eventlistener
spec:
  triggerGroups:
  - name: github-pr-group
    interceptors:
    - name: "validate GitHub payload and filter on eventType"
      ref:
        name: "github"
      params:
      - name: "secretRef"
        value:
          secretName: github-secret
          secretKey: secretToken
      - name: "eventTypes"
        value: ["pull_request"]
    triggerSelector:
      labelSelector:
        matchLabels:
          type: github-pr

This configuration would first process any event that is sent to the EventListener and determine if it matches the outlined conditions. If it passes these conditions, it will use the triggerSelector matching criteria to determine the target Trigger resources to continue processing.

Any extensions fields added during triggerGroup processing are passed to the downstream Trigger execution. This allows for shared data across all Triggers that are processed after group execution completes. As an example, extensions.myfield would be available to all Trigger resources matched by this group:

apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: eventlistener
spec:
  triggerGroups:
  - name: cel-filter-group
    interceptors:
    - name: "validate body and add field"
      ref:
        name: "cel"
      params:
      - name: "filter"
        value: "body.action in ['opened', 'reopened']"
      - name: "overlays"
        value:
        - key: myfield
          expression: "body.pull_request.head.sha.truncate(7)"
    triggerSelector:
      namespaceSelector:
        matchNames:
        - foo
      labelSelector:
        matchLabels:
          type: cel-preprocessed

At this time, each TriggerGroup determines its own downstream Triggers, so if two separate groups select the same downstream Trigger resources, it may be executed multiple times. If you use this feature, ensure that Trigger resources are labeled to be queried by the appropriate set of TriggerGroups.

Specifying `Resources`

You can optionally customize the sink deployment for your EventListener using the resources field. It accepts the following types of objects:

Kubernetes Resource using the kubernetesResource field
Custom Resource objects via the CustomResource field

Legal values for the PodSpec sub-fields for both kubernetesResource and CustomResource are:

ServiceAccountName
NodeSelector
Tolerations
Containers
Affinity
TopologySpreadConstraints
SecurityContext

Legal values for the Containers sub-field for kubernetesResource and CustomResource are:

kubernetesResource:

Resources
Env
LivenessProbe
ReadinessProbe
StartupProbe
SecurityContext

CustomResource:

Resources
Env
SecurityContext

Specifying a `kubernetesResource` object

Below is an example resources: field definition specifying a kubernetesResource object:

spec:
  resources:
    kubernetesResource:
      serviceType: NodePort
      servicePort: 80
      spec:
        template:
          metadata:
            labels:
              key: "value"
            annotations:
              key: "value"
          spec:
            serviceAccountName: tekton-triggers-github-sa
            securityContext:
              runAsNonRoot: true
            nodeSelector:
              app: test
            tolerations:
            - key: key
              value: value
              operator: Equal
              effect: NoSchedule
            containers:
            - securityContext:
                readOnlyRootFilesystem: true

Specifying `Service` configuration

The type and port for the Service created for the EventListener can be configured via the ServiceType and ServicePort specifications respectively. By default, the Service type is set to ClusterIP and port is set to 8080.

spec:
  resources:
    kubernetesResource:
      serviceType: LoadBalancer
      servicePort: 8128

If you use a loadbalancer service, you can optionally define a LoadBalancerClass with the ServiceLoadBalancerClass attribute.

spec:
  resources:
    kubernetesResource:
      serviceType: LoadBalancer
      serviceLoadBalancerClass: internal

Specifying `Replicas`

You can optionally use the replicas field to instruct Tekton Triggers to deploy more than one instance of your EventListener in individual Kubernetes Pods. If you do not specify this value, the default number of instances (and thus, the number of respective Pods) per EventListener is 1. If you set a value for the replicas field while creating or upgrading the EventListener's YAML file, that value overrides any value you set manually later as well as a value set by any other deployment mechanism, such as HPA.

Specifying a `CustomResource` object

You can specify a Kubernetes Custom Resource object using the CustomResource field. This field has one sub-field, runtime.RawExtension that allows you to specify dynamic objects.

Contract for the `CustomResource` object

The CustomResource object must abide by the contract shown below.

Contract-mandated CRD structure for the spec field:

   spec:
     template:
       metadata:
       spec:

Contract-mandated CRD structure for the status field:

type EventListenerStatus struct {
  duckv1beta1.Status `json:",inline"`

  // EventListener is addressable via the DNS address of the sink.
  duckv1alpha1.AddressStatus `json:",inline"`
}

Note: The CRD must follow the WithPod{} spec.

Below is an example resources: field definition specifying a CustomResource object using a Knative Service:

Note: This example assumes that Knative is installed on your cluster.

spec:
  resources:
    customResource:
      apiVersion: serving.knative.dev/v1
      kind: Service
#      metadata:
#        name: knativeservice # name is optional; if not specified, Triggers substitutes the EventListener's name with an "el-" prefix, for example: el-github-knative-listener
      spec:
        template:
          spec:
            serviceAccountName: tekton-triggers-example-sa
            containers:
            - resources:
                requests:
                  memory: "64Mi"
                  cpu: "250m"
                limits:
                  memory: "128Mi"
                  cpu: "500m"

Specifying `Interceptors`

An Interceptor is a “catch-all” event processor for a specific platform that runs before the TriggerBinding. It allows you to perform payload filtering, verification (using a secret), transformation, define and test trigger conditions, and implement other useful processing. Once the event data passes through an Interceptor, it then goes to the Trigger before you pass the payload data to the TriggerBinding. You can also use an Interceptor to modify the behavior of the associated Trigger.

For more information, see Interceptors.

Constraining `EventListeners` to specific namespaces

You can optionally specify a list of namespaces in which your EventListener will search for Triggers and instantiate the specified Tekton objects using the namespaceSelector field.

If you omit this field, your EventListener will only recognize Triggers specified in its definition or found under one or more specified target labels.

Below is an example namespaceSelector field that configures the EventListener to use the foo and bar namespaces:

  namespaceSelector:
    matchNames:
    - foo
    - bar

If you want your EventListener to recognize Triggers across your entire cluster, use a wildcard between quote as the only namespace:

  namespaceSelector:
    matchNames:
    - "*"

At present, if an EventListeners has Triggers inside its own spec as well as namespace-selector, Triggers in spec as well as in selected namespaces will be processed for a request. Triggers inside EventListener spec when using namespace-selector mode is deprecated and ability to specify both will be removed.

Constraining `EventListeners` to specific labels

You can optionally specify the labels for which your EventListener recognizes Triggers and instantiates the specified Tekton objects using the labelSelector field. This field uses the standard Kubernetes labelSelector mechanism and supports the matchExpressions sub-field. If you omit the labelSelector field, the EventListener accepts all resource labels.

Below is an example labelSelector field definition that constrains your EventListener to only recognize Triggers within its own namespace that are labeled foo=bar:

  labelSelector:
    matchLabels:
      foo: bar

Below is an example labelSelector field definition that uses the matchExpression sub-field to specify expressions that allow the EventListener to recognize Triggers across all namespaces in the cluster:

  namespaceSelector:
    matchNames:
    - *
  labelSelector:
    matchExpressions:
      - {key: environment, operator: In, values: [dev,stage]}
      - {key: trigger-phase, operator: NotIn, values: [testing]}

Specifying `EventListener` timeouts

An EventListener times out if it cannot process an event request within a timeout specified in controller.yaml. The timeouts are as follows:

-el-readtimeout: Read timeout; default is 5 seconds.
-el-writetimeout: Write timeout; default is 40 seconds.
-el-idletimeout: Idle timeout; default is 120 seconds.
-el-timeouthandler: Server route handler timeout; default is 30 seconds.

Disabling Payload Validation

To disable incoming payload validation for an EventListener, you can define an annotation tekton.dev/payload-validation: false on EventListener.

apiVersion: triggers.tekton.dev/v1alpha1
kind: EventListener
metadata:
  name: eventlistener
  annotations:
    tekton.dev/payload-validation: "false"

By default, payload validation is enabled and will be disabled only if the annotation is defined. Removing the annotation will enable the payload validation.

Labels in `EventListeners`

By default, each EventListener automatically attaches the following labels to all resources it instantiates:

Name	Description
triggers.tekton.dev/eventlistener	Name of the `EventListener` that instantiated the resource.
triggers.tekton.dev/trigger	Name of the `Trigger` that instantiated the resource.
triggers.tekton.dev/eventid	UID of the incoming event.

Note: Because they’re used as labels, EventListener and Trigger names must conform to the Kubernetes syntax and character set requirements.

Annotations in `EventListeners`

Tekton Triggers propagates all annotations that you include in your EventListener to the Kubernetes service and deployment created by that EventListener. Keep in mind that annotations propagated from the EventListener override annotations already present in its Kubernetes service and deployment.

Below is an example load balancer protocol annotation in an EventListener definition that automatically propagates to the EventListener's service:

apiVersion: triggers.tekton.dev/v1alpha1
kind: EventListener
metadata:
  name: eventlistener
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: https

Understanding `EventListener` response

An EventListener responds with a 202 ACCEPTED HTTP response when the EventListener has been able to process the request and selected the appropriate triggers to process based off the EventListener configuration.

After detecting an event, the EventListener responds with the following message:

{
  "eventListener": "listener",
  "namespace": "default",
  "eventListenerUID": "ea71a6e4-9531-43a1-94fe-6136515d938c",
  "eventID": "14a657c3-6816-45bf-b214-4afdaefc4ebd"
}

eventListenerUID - UID of the target EventListener.
eventID - UID assigned to this event request

Response to CloudEvents

EventListener can acts as sink for CloudEvents. When it acts as such, then its response is different from above.

EventListener sends out this cloudevent as response assuming an EventListener with name listener in the default namespace with uuid ea71a6e4-9531-43a1-94fe-6136515d938c:

type: dev.tekton.event.triggers.accepted.v1
source: listener
subject: default.listener accepted eventID
id: 14a657c3-6816-45bf-b214-4afdaefc4ebd

id is assigned eventID.

It also has following data:

{
  "eventListener": "listener",
  "namespace": "default",
  "eventListenerUID": "ea71a6e4-9531-43a1-94fe-6136515d938c",
  "eventID": "14a657c3-6816-45bf-b214-4afdaefc4ebd"
}

eventID - UID assigned to this event request

Deprecated Fields

These fields are included in EventListener responses, but will be removed in a future release.

eventListener - name of the target EventListener. Use eventListenerUID instead.
namespace - namespace of the target EventListener. Use eventListenerUID instead.

TLS HTTPS support in `EventListeners`

Tekton Triggers supports both HTTP and TLS-based HTTPS connections. To configure your EventListener for TLS, add the TLS_CERT and TLS_KEY reserved environment variables using the secretKeyRef variable type, then specify a secret containing the cert and key files. See TEP-0027 and our TLS configuration example for more information.

Obtaining the status of deployed `EventListeners`

Use the following command to get a list of EventListeners deployed on your cluster along with their statuses:

kubectl get el

You will get a response similar to the following:

NAME                       ADDRESS                                                             AVAILABLE   REASON                     READY   REASON
tls-listener-interceptor   http://el-tls-listener-interceptor.default.svc.cluster.local        True        MinimumReplicasAvailable

Where for each returned line, the column values are, from left to right:

NAME - name of the EventListener
ADDRESS - IP address or URL of the EventListener
AVAILABLE - readiness state of the associated Deployment and Service
REASON - reason for the value displayed in the AVAILABLE column
READY - readiness state of the Kubernetes Custom Resource object specified in the EventListener
REASON - reason for the value displayed in the READY column

Note: The status messaging described above is being refactored. For more information, see Issue 932.

Configuring logging for `EventListeners`

You can configure logging for your EventListeners using the config-logging-triggers ConfigMap located in the tekton-pipelines namespace (config-logging.yaml). Tekton Triggers automatically reconciles this configmap into environment variables on your event listener deployment.

To access your EventListener logs, query your cluster for Pods whose eventlistener label matches the name of your EventListener object. For example:

kubectl get pods --selector eventlistener=my-eventlistener

Configuring metrics for `EventListeners`

The following pipeline metrics are available on the eventlistener Service on port 9000.

Name	Type	Labels/Tags	Status
`eventlistener_triggered_resources`	Counter	`kind`=<kind>	experimental
`eventlistener_event_received_count`	Counter	`status`=<status>	experimental
`eventlistener_http_duration_seconds_[bucket, sum, count]`	Histogram	-	experimental

Several kinds of exporters can be configured for an EventListener, including Prometheus, Google Stackdriver, and many others. You can configure metrics using the config-observability-triggers config map in the EventListener namespaces. There is a config-observability-triggers configmap in the tekton-pipelines namespace that can be configured for the operation of the Triggers webhook and controller components.

See the Knative documentation for more information about available exporters and configuration values.

Exposing an `EventListener` outside of the cluster

EventListeners create an underlying Kubernetes service (unless a user specifies a customResource EventListener deployment). By convention, this service is the same name as the EventListener prefixed with el. So, an EventListener named foo will create a service called el-foo.

This service, by default is of type ClusterIP which means it is only accessible within the cluster on which it is running. You can expose this service as you would with any regular Kubernetes service. A few ways are highlighted below:

Using a LoadBalancer Service type
Using a Kubernetes Ingress object
Using the NGINX Ingress Controller
Using OpenShift Route

Exposing an `EventListener` using a `LoadBalancer` Service

If your Kubernetes cluster supports external load balancers, you can set the serviceType field to LoadBalancer to switch the Kubernetes service type:

spec:
  resources:
    kubernetesResource:
      serviceType: LoadBalancer

Note: You can find the external IP of this service by running kubectl get svc/el-${EVENTLISTENER-NAME} -o=jsonpath='{.status.loadBalancer.ingress[0].ip}'

Exposing an `EventListener` using a Kubernetes `Ingress` object

You can expose the service created by the EventListener using a regular Kubernetes Ingress. To do this, you may first have to change the serviceType to NodePort:

spec:
  resources:
    kubernetesResource:
      serviceType: NodePort

You can also use the Tekton create-ingress task to configure an Ingress object using self-signed certificates.

Exposing an `EventListener` using Openshift Route

Below are instructions for configuring an OpenShift 4.2 cluster running API version v1.14.6+32dc4a0. For more information, see Route Configuration.

Obtain the name of your EventListener service:

 oc get el <EVENTLISTENR_NAME> -o=jsonpath='{.status.configuration.generatedName}'

Expose the EventListener service:

 oc expose svc/[el-listener] # REPLACE el-listener WITH YOUR SERVICE NAME FROM STEP 1

Obtain the IP address of the exposed route:

 oc get route el-listener  -o=jsonpath='{.spec.host}' # REPLACE el-listener WITH YOUR SERVICE NAME FROM STEP 1

Test the configuration with curl or set up a GitHub Webhook that sends events to it.

Understanding the deployment of an `EventListener`

Below is a high-level walkthrough through the deployment of an EventListener using a GitHub example provided by Tekton Triggers.

Instantiate the example EventListener on your cluster:
```
kubectl create -f https://github.com/tektoncd/triggers/tree/main/examples/v1beta1/github
```
Tekton Triggers creates a new Deployment and Service for the EventListener. using the EventListener definition, metadata.labels, and pre-existing values such as container Image, Name, and Port. Tekton Triggers uses the EventListener name prefixed with el- to name the Deployment and Service when instantiating them. For example, if the EventListener name is foo, the Deployment and Service names are named el-foo.

Use kubectl to verify the Deployment is running on your cluster:

kubectl get deployment
NAME                             READY   UP-TO-DATE   AVAILABLE   AGE
el-github-listener-interceptor   1/1     1            1           11s

Use kubectl to verify the Service is running on your cluster:

kubectl get svc
NAME                             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
el-github-listener-interceptor   ClusterIP   10.99.188.140   <none>        8080/TCP   52s

Obtain the URL on which the EventListener is listening for events:

kubectl get eventlistener
NAME                          ADDRESS                                                              AVAILABLE   REASON
github-listener-interceptor   http://el-github-listener-interceptor.ptest.svc.cluster.local:8080   True        MinimumReplicasAvailable

See our GitHub EventListener example to try instantiating an EventListener locally.

Deploying `EventListeners` in multi-tenant scenarios

EventListeners are effectively Tekton clients that use HTTP to bypass the normal Kubernetes authentication mechanism established through kubeconfig files and the kubectl config command tree. Because of this, you must be conscious of your configuration decisions, such as:

How to securely expose each EventListener to the outside of your cluster,
How to securely control how each EventListener and its associated objects, such as Interceptors, interact with data on your cluster.

At the minimum, each EventListener specifies its own Kubernetes Service account as explained earlier, and it acts on all events it receives with the permissions of that service account. If your business needs mandate more granular permission control across the Triggers and Interceptors specified in your EventListeners, you have the following options:

Deploy each EventListener in its own namespace
Deploy multiple EventListeners in the same namespace
Specify a separate service account for each Trigger

Deploying each `EventListener` in its own namespace

In this scenario, you create multiple EventListeners that in turn use a variety of Triggers and Interceptors, each EventListener gets its own namespace. This way, you can use a different service account for each namespace and tailor the permissions of those accounts to the functionality of their corresponding EventListeners. Because creating a namespace often instantiates the necessary service accounts based on pre-configured permissions, this also simplifies the deployment process as you simply need to update the permissions associated with those accounts.

However, this approach has the following drawbacks:

Namespaces with separately associated Secrets and ServiceAccounts can be the most expensive items in the Kubernetes etcd store; on large clusters, the capacity of the etcd store can become a concern.
Since each EventListener requires its own HTTP port to listen for events, you must configure your network to allow access to each corresponding IP address and port combination unless you configure an ingress abstraction layer, such as the Kubernetes Ingress object,or OpenShift Route.

Deploying multiple `EventListeners` in the same namespace

In this scenario, you create multiple EventListeners in the same namespace. This will require customization of the associated service account(s), secret(s), and RBAC, since the automatically generated defaults are not always ideal, but you will not incur a significant etcd store cost as in the multiple namespace scenario. Network security and configuration overhead concerns, however, still apply as described earlier. You can also achieve a similar result by specifying a separate service account for each Trigger used across your EventListener pool at the cost of increased administration overhead.

Cloud Events during Trigger Processing

The cloud event that is sent to a target URI during Trigger processing. The types of events send for now are:

Type	Description
dev.tekton.event.triggers.started.v1	triggers processing started in eventlistener
dev.tekton.event.triggers.successful.v1	triggers processing successful and a resource created
dev.tekton.event.triggers.failed.v1	triggers failed in eventlistener
dev.tekton.event.triggers.done.v1	triggers processing done in eventlistener handle

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

`EventListeners`

If you need to modify, filter, or validate the event payload data before passing it to a TriggerBinding, you can optionally specify one or more Interceptors.

Structure of an `EventListener`

An EventListener definition consists of the following fields:

Required:
- apiVersion - specifies the target API version, for example triggers.tekton.dev/v1alpha1
- kind - specifies that this Kubernetes resource is an EventListener object
- metadata - specifies data that uniquely identifies this EventListener object, for example a name
- spec - specifies the configuration of your EventListener:
  - serviceAccountName - Specifies the ServiceAccount the EventListener will use to instantiate Tekton resources
Optional:
- triggers - specifies a list of Triggers to execute upon event detection
- cloudEventURI - specifies the URI for cloudevent sink
- resources - specifies the resources that will be available to the event listening service
- namespaceSelector - specifies the namespace for the EventListener; this is where the EventListener looks for the specified Triggers and stores the Tekton objects it instantiates upon event detection
- labelSelector - specifies the labels for which your EventListener recognizes Triggers and instantiates the specified Tekton objects

See our Tekton Triggers examples for ready-to-use example EventListener definitions.

Specifying the Kubernetes service account

You must specify a Kubernetes service account in the serviceAccountName field that the EventListener will use to instantiate Tekton objects.

Tekton Trigger creates 2 clusterroles while installing with necessary permissions required for an eventlistener. You can directly create bindings for your serviceaccount with the clusterroles.

A Kubernetes RoleBinding with tekton-triggers-eventlistener-roles clusterrole.
A Kubernetes ClusterRoleBinding with tekton-triggers-eventlistener-clusterroles clusterrole.

You can checkout an example here.
If you’re using namespaceSelectors in your EventListener, you will have to create an additional ClusterRoleBinding with tekton-triggers-eventlistener-roles clusterrole.

Specifying `Triggers`

name - (optional) a valid Kubernetes name that uniquely identifies the Trigger
interceptors - (optional) a list of Interceptors that will process event payload data before passing it to the associated TriggerBinding
bindings - (optional) a list of TriggerBindings for this Trigger; you can either reference existing TriggerBindings or embed their definitions directly
template - (optional) a TriggerTemplate for this Trigger; you can either reference an existing TriggerTemplate or embed its definition directly
triggerRef - (optional) a reference to an external Trigger

Below is an example Trigger definition that references the desired TriggerBindings, TriggerTemplates, and Interceptors:

triggers:
  - name: trigger-1
    interceptors:
      - github:
          eventTypes: ["pull_request"]
    bindings:
      - ref: pipeline-binding # Reference to a TriggerBinding object
      - name: message # Embedded Binding
        value: Hello from the Triggers EventListener!
    template:
      ref: pipeline-template

Below is an example Trigger definition that specifies a reference to an external Trigger object:

triggers:
    - triggerRef: trigger

Below is an example Trigger definition that embeds a triggerTemplate definition directly:

triggers:
  - name: "my-trigger"
    template:
      spec:
        params:
          - name: "my-param-name"
        resourceTemplates:
        - apiVersion: "tekton.dev/v1beta1"
          kind: TaskRun
          metadata:
            generateName: "pr-run-"
          spec:
            taskSpec:
              steps:
              - image: ubuntu
                script: echo "hello there"

triggers:
  - name: trigger-1
    serviceAccountName: trigger-1-sa
    interceptors:
      - github:
          eventTypes: ["pull_request"]
    bindings:
      - ref: pipeline-binding
      - ref: message-binding
    template:
      ref: pipeline-template

You must update the Role assigned to the service account specified in the EventListener as shown below to allow it to impersonate the service account specified in the Trigger:

rules:
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["impersonate"]

Specifying `cloudEventURI`

Specifying the URI for cloud event sink which receives cloud events during Trigger Processing.

spec:
  cloudEventURI: http://eventlistener.free.beeceptor.com

Specifying `TriggerGroups`

A TriggerGroup definition specifies the following fields:

name - (optional) a valid Kubernetes name that uniquely identifies the TriggerGroup
interceptors - a list of Interceptors that will process event payload data before passing it to the downstream Triggers
triggerSelector - a combination of a Kubernetes labelSelector and a namespaceSelector as defined later in this document. These two fields work together to define the Triggers that will be processed once Interceptors processing completes.

Below is an example EventListener that defines an inline triggerGroup:

apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: eventlistener
spec:
  triggerGroups:
  - name: github-pr-group
    interceptors:
    - name: "validate GitHub payload and filter on eventType"
      ref:
        name: "github"
      params:
      - name: "secretRef"
        value:
          secretName: github-secret
          secretKey: secretToken
      - name: "eventTypes"
        value: ["pull_request"]
    triggerSelector:
      labelSelector:
        matchLabels:
          type: github-pr

apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: eventlistener
spec:
  triggerGroups:
  - name: cel-filter-group
    interceptors:
    - name: "validate body and add field"
      ref:
        name: "cel"
      params:
      - name: "filter"
        value: "body.action in ['opened', 'reopened']"
      - name: "overlays"
        value:
        - key: myfield
          expression: "body.pull_request.head.sha.truncate(7)"
    triggerSelector:
      namespaceSelector:
        matchNames:
        - foo
      labelSelector:
        matchLabels:
          type: cel-preprocessed

Specifying `Resources`

You can optionally customize the sink deployment for your EventListener using the resources field. It accepts the following types of objects:

Kubernetes Resource using the kubernetesResource field
Custom Resource objects via the CustomResource field

Legal values for the PodSpec sub-fields for both kubernetesResource and CustomResource are:

ServiceAccountName
NodeSelector
Tolerations
Containers
Affinity
TopologySpreadConstraints
SecurityContext

Legal values for the Containers sub-field for kubernetesResource and CustomResource are:

kubernetesResource:

Resources
Env
LivenessProbe
ReadinessProbe
StartupProbe
SecurityContext

CustomResource:

Resources
Env
SecurityContext

Specifying a `kubernetesResource` object

Below is an example resources: field definition specifying a kubernetesResource object:

spec:
  resources:
    kubernetesResource:
      serviceType: NodePort
      servicePort: 80
      spec:
        template:
          metadata:
            labels:
              key: "value"
            annotations:
              key: "value"
          spec:
            serviceAccountName: tekton-triggers-github-sa
            securityContext:
              runAsNonRoot: true
            nodeSelector:
              app: test
            tolerations:
            - key: key
              value: value
              operator: Equal
              effect: NoSchedule
            containers:
            - securityContext:
                readOnlyRootFilesystem: true

Specifying `Service` configuration

spec:
  resources:
    kubernetesResource:
      serviceType: LoadBalancer
      servicePort: 8128

If you use a loadbalancer service, you can optionally define a LoadBalancerClass with the ServiceLoadBalancerClass attribute.

spec:
  resources:
    kubernetesResource:
      serviceType: LoadBalancer
      serviceLoadBalancerClass: internal

Specifying `Replicas`

Specifying a `CustomResource` object

You can specify a Kubernetes Custom Resource object using the CustomResource field. This field has one sub-field, runtime.RawExtension that allows you to specify dynamic objects.

Contract for the `CustomResource` object

The CustomResource object must abide by the contract shown below.

Contract-mandated CRD structure for the spec field:

   spec:
     template:
       metadata:
       spec:

Contract-mandated CRD structure for the status field:

type EventListenerStatus struct {
  duckv1beta1.Status `json:",inline"`

  // EventListener is addressable via the DNS address of the sink.
  duckv1alpha1.AddressStatus `json:",inline"`
}

Note: The CRD must follow the WithPod{} spec.

Below is an example resources: field definition specifying a CustomResource object using a Knative Service:

Note: This example assumes that Knative is installed on your cluster.

spec:
  resources:
    customResource:
      apiVersion: serving.knative.dev/v1
      kind: Service
#      metadata:
#        name: knativeservice # name is optional; if not specified, Triggers substitutes the EventListener's name with an "el-" prefix, for example: el-github-knative-listener
      spec:
        template:
          spec:
            serviceAccountName: tekton-triggers-example-sa
            containers:
            - resources:
                requests:
                  memory: "64Mi"
                  cpu: "250m"
                limits:
                  memory: "128Mi"
                  cpu: "500m"

Specifying `Interceptors`

For more information, see Interceptors.

Constraining `EventListeners` to specific namespaces

You can optionally specify a list of namespaces in which your EventListener will search for Triggers and instantiate the specified Tekton objects using the namespaceSelector field.

If you omit this field, your EventListener will only recognize Triggers specified in its definition or found under one or more specified target labels.

Below is an example namespaceSelector field that configures the EventListener to use the foo and bar namespaces:

  namespaceSelector:
    matchNames:
    - foo
    - bar

If you want your EventListener to recognize Triggers across your entire cluster, use a wildcard between quote as the only namespace:

  namespaceSelector:
    matchNames:
    - "*"

Constraining `EventListeners` to specific labels

Below is an example labelSelector field definition that constrains your EventListener to only recognize Triggers within its own namespace that are labeled foo=bar:

  labelSelector:
    matchLabels:
      foo: bar

  namespaceSelector:
    matchNames:
    - *
  labelSelector:
    matchExpressions:
      - {key: environment, operator: In, values: [dev,stage]}
      - {key: trigger-phase, operator: NotIn, values: [testing]}

Specifying `EventListener` timeouts

An EventListener times out if it cannot process an event request within a timeout specified in controller.yaml. The timeouts are as follows:

-el-readtimeout: Read timeout; default is 5 seconds.
-el-writetimeout: Write timeout; default is 40 seconds.
-el-idletimeout: Idle timeout; default is 120 seconds.
-el-timeouthandler: Server route handler timeout; default is 30 seconds.

Disabling Payload Validation

To disable incoming payload validation for an EventListener, you can define an annotation tekton.dev/payload-validation: false on EventListener.

apiVersion: triggers.tekton.dev/v1alpha1
kind: EventListener
metadata:
  name: eventlistener
  annotations:
    tekton.dev/payload-validation: "false"

By default, payload validation is enabled and will be disabled only if the annotation is defined. Removing the annotation will enable the payload validation.

Labels in `EventListeners`

By default, each EventListener automatically attaches the following labels to all resources it instantiates:

Name	Description
triggers.tekton.dev/eventlistener	Name of the `EventListener` that instantiated the resource.
triggers.tekton.dev/trigger	Name of the `Trigger` that instantiated the resource.
triggers.tekton.dev/eventid	UID of the incoming event.

Note: Because they’re used as labels, EventListener and Trigger names must conform to the Kubernetes syntax and character set requirements.

Annotations in `EventListeners`

Below is an example load balancer protocol annotation in an EventListener definition that automatically propagates to the EventListener's service:

apiVersion: triggers.tekton.dev/v1alpha1
kind: EventListener
metadata:
  name: eventlistener
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: https

Understanding `EventListener` response

After detecting an event, the EventListener responds with the following message:

{
  "eventListener": "listener",
  "namespace": "default",
  "eventListenerUID": "ea71a6e4-9531-43a1-94fe-6136515d938c",
  "eventID": "14a657c3-6816-45bf-b214-4afdaefc4ebd"
}

eventListenerUID - UID of the target EventListener.
eventID - UID assigned to this event request

Response to CloudEvents

EventListener can acts as sink for CloudEvents. When it acts as such, then its response is different from above.

EventListener sends out this cloudevent as response assuming an EventListener with name listener in the default namespace with uuid ea71a6e4-9531-43a1-94fe-6136515d938c:

type: dev.tekton.event.triggers.accepted.v1
source: listener
subject: default.listener accepted eventID
id: 14a657c3-6816-45bf-b214-4afdaefc4ebd

id is assigned eventID.

It also has following data:

{
  "eventListener": "listener",
  "namespace": "default",
  "eventListenerUID": "ea71a6e4-9531-43a1-94fe-6136515d938c",
  "eventID": "14a657c3-6816-45bf-b214-4afdaefc4ebd"
}

eventID - UID assigned to this event request

Deprecated Fields

These fields are included in EventListener responses, but will be removed in a future release.

eventListener - name of the target EventListener. Use eventListenerUID instead.
namespace - namespace of the target EventListener. Use eventListenerUID instead.

TLS HTTPS support in `EventListeners`

Obtaining the status of deployed `EventListeners`

Use the following command to get a list of EventListeners deployed on your cluster along with their statuses:

kubectl get el

You will get a response similar to the following:

NAME                       ADDRESS                                                             AVAILABLE   REASON                     READY   REASON
tls-listener-interceptor   http://el-tls-listener-interceptor.default.svc.cluster.local        True        MinimumReplicasAvailable

Where for each returned line, the column values are, from left to right:

NAME - name of the EventListener
ADDRESS - IP address or URL of the EventListener
AVAILABLE - readiness state of the associated Deployment and Service
REASON - reason for the value displayed in the AVAILABLE column
READY - readiness state of the Kubernetes Custom Resource object specified in the EventListener
REASON - reason for the value displayed in the READY column

Note: The status messaging described above is being refactored. For more information, see Issue 932.

Configuring logging for `EventListeners`

To access your EventListener logs, query your cluster for Pods whose eventlistener label matches the name of your EventListener object. For example:

kubectl get pods --selector eventlistener=my-eventlistener

Configuring metrics for `EventListeners`

The following pipeline metrics are available on the eventlistener Service on port 9000.

Name	Type	Labels/Tags	Status
`eventlistener_triggered_resources`	Counter	`kind`=<kind>	experimental
`eventlistener_event_received_count`	Counter	`status`=<status>	experimental
`eventlistener_http_duration_seconds_[bucket, sum, count]`	Histogram	-	experimental

See the Knative documentation for more information about available exporters and configuration values.

Exposing an `EventListener` outside of the cluster

Using a LoadBalancer Service type
Using a Kubernetes Ingress object
Using the NGINX Ingress Controller
Using OpenShift Route

Exposing an `EventListener` using a `LoadBalancer` Service

If your Kubernetes cluster supports external load balancers, you can set the serviceType field to LoadBalancer to switch the Kubernetes service type:

spec:
  resources:
    kubernetesResource:
      serviceType: LoadBalancer

Note: You can find the external IP of this service by running kubectl get svc/el-${EVENTLISTENER-NAME} -o=jsonpath='{.status.loadBalancer.ingress[0].ip}'

Exposing an `EventListener` using a Kubernetes `Ingress` object

You can expose the service created by the EventListener using a regular Kubernetes Ingress. To do this, you may first have to change the serviceType to NodePort:

spec:
  resources:
    kubernetesResource:
      serviceType: NodePort

You can also use the Tekton create-ingress task to configure an Ingress object using self-signed certificates.

Exposing an `EventListener` using Openshift Route

Below are instructions for configuring an OpenShift 4.2 cluster running API version v1.14.6+32dc4a0. For more information, see Route Configuration.

Obtain the name of your EventListener service:

 oc get el <EVENTLISTENR_NAME> -o=jsonpath='{.status.configuration.generatedName}'

Expose the EventListener service:

 oc expose svc/[el-listener] # REPLACE el-listener WITH YOUR SERVICE NAME FROM STEP 1

Obtain the IP address of the exposed route:

 oc get route el-listener  -o=jsonpath='{.spec.host}' # REPLACE el-listener WITH YOUR SERVICE NAME FROM STEP 1

Test the configuration with curl or set up a GitHub Webhook that sends events to it.

Understanding the deployment of an `EventListener`

Below is a high-level walkthrough through the deployment of an EventListener using a GitHub example provided by Tekton Triggers.

Instantiate the example EventListener on your cluster:
```
kubectl create -f https://github.com/tektoncd/triggers/tree/main/examples/v1beta1/github
```
Tekton Triggers creates a new Deployment and Service for the EventListener. using the EventListener definition, metadata.labels, and pre-existing values such as container Image, Name, and Port. Tekton Triggers uses the EventListener name prefixed with el- to name the Deployment and Service when instantiating them. For example, if the EventListener name is foo, the Deployment and Service names are named el-foo.

Use kubectl to verify the Deployment is running on your cluster:

kubectl get deployment
NAME                             READY   UP-TO-DATE   AVAILABLE   AGE
el-github-listener-interceptor   1/1     1            1           11s

Use kubectl to verify the Service is running on your cluster:

kubectl get svc
NAME                             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
el-github-listener-interceptor   ClusterIP   10.99.188.140   <none>        8080/TCP   52s

Obtain the URL on which the EventListener is listening for events:

kubectl get eventlistener
NAME                          ADDRESS                                                              AVAILABLE   REASON
github-listener-interceptor   http://el-github-listener-interceptor.ptest.svc.cluster.local:8080   True        MinimumReplicasAvailable

See our GitHub EventListener example to try instantiating an EventListener locally.

Deploying `EventListeners` in multi-tenant scenarios

How to securely expose each EventListener to the outside of your cluster,
How to securely control how each EventListener and its associated objects, such as Interceptors, interact with data on your cluster.

Deploy each EventListener in its own namespace
Deploy multiple EventListeners in the same namespace
Specify a separate service account for each Trigger

Deploying each `EventListener` in its own namespace

However, this approach has the following drawbacks:

Namespaces with separately associated Secrets and ServiceAccounts can be the most expensive items in the Kubernetes etcd store; on large clusters, the capacity of the etcd store can become a concern.
Since each EventListener requires its own HTTP port to listen for events, you must configure your network to allow access to each corresponding IP address and port combination unless you configure an ingress abstraction layer, such as the Kubernetes Ingress object,or OpenShift Route.

Deploying multiple `EventListeners` in the same namespace

Cloud Events during Trigger Processing

The cloud event that is sent to a target URI during Trigger processing. The types of events send for now are:

Type	Description
dev.tekton.event.triggers.started.v1	triggers processing started in eventlistener
dev.tekton.event.triggers.successful.v1	triggers processing successful and a resource created
dev.tekton.event.triggers.failed.v1	triggers failed in eventlistener
dev.tekton.event.triggers.done.v1	triggers processing done in eventlistener handle

Tekton – Welcome to Tekton

Docs: Clone a git repository with Tekton

Prerequisites

Pull source code from git

Create the Pipeline

Create the PipelineRun

Git authentication

Use the source code in a second task

Run the Pipeline

Install a Task from Tekton Hub

Apply the files

Full code samples

Further reading

Docs: Content guidelines

Types of content

Structure

Style and tone

Docs: Contribute Code

Getting started

Finding something to work on

Key resources

I need help!

Docs: Getting started with Tasks

Prerequisites

Create a Kubernetes cluster

Install Tekton Pipelines

Create and run a basic Task

Cleanup

Further Reading:

Docs: Local Kubernetes cluster

Further reading

Docs: Overview

What is Tekton?

Who uses Tekton?

What are the benefits of Tekton?

What are the components of Tekton?

How do I work with Tekton?

What can I do with Tekton?

When to use which?

I want to learn more!

Docs:

Tekton Config

Target Namespace

Target Namespace Metadata

Profile

Config

Pipeline

Chain

Result

Pruner

Note:

Pruner Namespace annotations

Note:

Scheduler

Hub cluster

Spoke cluster

OpenShift: proxy-aae Kueue namespace

Addon

Hub

Dashboard

Resolvers

OpenShiftPipelinesAsCode

Remote Hub Catalogs

Example: Configuring a Custom Hub Catalog

Example: Configuring Multiple Hub Catalogs

Referencing Tasks from Custom Catalogs

Event based pruner

Basic Configuration

Configuration Levels

Pruning Fields

Namespace-Level Configuration

Complete Example

Additional fields as options

ConfigMaps

Deployments

StatefulSets

HorizontalPodAutoscalers

webhookConfigurationOptions

Vault:

Tekton Config

Additional fields as `options`

Additional fields as `options`

Additional fields as `options`