Maintaining remote Tekton pipelines

This article assumes knowledge of Tekton remote pipelines. If this is not the case, please read more about this feature before proceeding.

Implementing this guideline

Prerequisites

Having a repository to store shared Pipelines and Tasks.

If the repository is private, be sure to have a Secret in your Konflux tenant namespace to be able to clone it

Basic definitions

Procedures

Add Tekton Pipelines and Tasks in the repository. Here is a suggested repository structure:

.
├── .tekton
│   ├── <repository-name>-pipelines-pull-request.yaml (1)
│   ├── <repository-name>-pipelines-push.yaml (2)
│   ├── pipelines
│   │   ├── remote-pipeline1.yaml
│   │   └── remote-pipeline2.yaml
│   └── tasks
│       ├── remote-task1.yaml
│       └── remote-task2.yaml
└── renovate.json (3)

1	Used by Konflux to monitor pull requests.
2	Used by Konflux to monitor pushes.
3	Renovate/MintMaker configuration.

Use Pipelines as Code’s resolver with this structure to reference pipelines and tasks with a simple pipelineRef:

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata: ... (1)
spec:
  pipelineRef:
    name: pipeline-1 (2)

1	Omitted for brevity. No additional annotations are required to reference the pipeline or task if they exist in the `.tekton` directory.
2	Specify the name of the pipeline. Note: this is the pipeline’s `metadata.name`, not the filename.

This has the added benefits of faster resolution and fewer API requests than other pipeline resolution methods because Pipelines as Code already parses the Pipelines and Tasks from the .tekton directory when looking for PipelineRuns to match.

Use git resolver

Do not use the git resolver to reference pipelines and tasks that are already in the .tekton directory of the same repository. Pipelines as Code automatically resolves resources from this directory, so using the git resolver for them is unnecessary and results in additional API requests.

Use the git resolver to reference a pipeline that exists in another repository. To start referencing a remote Pipeline from a PipelineRun by using the git resolver, replace pipelineSpec with pipelineRef:

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata: ... (1)
spec:
  pipelineRef:
    resolver: git
    params:
      - name: org
        value: redhat
      - name: scmType
        value: gitlab
      - name: serverURL
        value: https://gitlab.com
      - name: url
        value: "https://gitlab.com/your-group-name/your-repo-name.git"
      - name: revision
        value: main (2)
      - name: pathInRepo
        value: "pipelines/your-pipeline-name.yaml" (3)
      - name: token
        value: pipelines-as-code-secret (4)
      - name: tokenKey
        value: password (5)

1	Omitted for brevity.
2	Specify a branch to target.
3	Repository path to the pipeline definition YAML file.
4	Name of the Secret. Read how to create secrets for your builds section for more information on how to create this.
5	Name of the attribute within your Secret, that stores the password/token.

Benefits of this guideline

This approach allows a team or an individual contributor to manage multiple custom Pipelines from a single repository as source of truth. But there also other good reasons:

Pipelines are stored in a Git repository and fetched during execution, eliminating the need to maintain local or static pipeline definitions.
Teams can leverage Git’s versioning to access specific pipeline branches.
In case of issues, it’s very simple to rollback to a previous pipeline version, and apply it globally among the Konflux Components.
Reduced maintenance overhead of keeping task references up to date across multiple components.

Potential drawbacks

Although Tekton remote pipelines is a huge improvement, it brings a drawback; the Pipeline CRDs will not be stored in the Konflux Component repository anymore, so MintMaker will not be able to update the TaskRef digests for us.

The suggested approach is to onboard the repository where the shared pipelines are stored as a Konflux Component, so that Konflux and MintMaker will be able to discover and update digests for us.

To achieve this, configure and extend MintMaker properly, so that it will be able to discover Tekton Pipelines and take care of them in custom paths:

renovate.json

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "tekton": {
    "fileMatch": ["\\.yaml$", "\\.yml$"], (1)
    "includePaths": ["pipelines/**", "tasks/**"], (2)
    "automerge": true (3)
  }
}

Tekton pipelines to match.

Paths where to look for Tekton Pipelines to update.

Define whether MintMaker must take care of PRs and automerge them or not.

MintMaker will read the default configuration from "https://docs.renovatebot.com/renovate-schema.json" and will extend it using the subsequent custom settings.

Create a Konflux Application and a Konflux Component to reference the repository and branch name.