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 workspace to be able to clone it

Basic definitions

Procedures
  1. Add Tekton Pipelines and Tasks in the repository. A suggested repository structure would be:

    .
    ├── .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 git resolver

To start referencing a remote Pipeline from a PipelineRun using a 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:

  1. Pipelines are stored in a Git repository and fetched during execution, eliminating the need to maintain local or static pipeline definitions.

  2. Teams can leverage Git’s versioning to access specific pipeline branches.

  3. In case of issues, it’s very simple to rollback to a previous pipeline version, and apply it globally among the Konflux Components.

  4. Reduced maintenance overhead of keeping task references up to date across multiple components.

Potential drawbacks

Although Tekton remote pipelines is a huge improvement, it comes with 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)
  }
}
1 Tekton pipelines to match.
2 Paths where to look for Tekton Pipelines to update.
3 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.

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