Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Creating CI/CD pipelines

Red Hat OpenShift Pipelines 1.10

Getting started with creating and running tasks and pipelines in OpenShift Pipelines

Red Hat OpenShift Documentation Team

Abstract

This document provides information about creating and running tasks and pipelines in OpenShift Pipelines.

With Red Hat OpenShift Pipelines, you can create a customized CI/CD solution to build, test, and deploy your application.

To create a full-fledged, self-serving CI/CD pipeline for an application, perform the following tasks:

  • Create custom tasks, or install existing reusable tasks.
  • Create and define the delivery pipeline for your application.

  • Provide a storage volume or filesystem that is attached to a workspace for the pipeline execution, using one of the following approaches:

    • Specify a volume claim template that creates a persistent volume claim
    • Specify a persistent volume claim
  • Create a PipelineRun object to instantiate and invoke the pipeline.
  • Add triggers to capture events in the source repository.

This section uses the pipelines-tutorial example to demonstrate the preceding tasks. The example uses a simple application which consists of:

  • A front-end interface, pipelines-vote-ui, with the source code in the pipelines-vote-ui Git repository.
  • A back-end interface, pipelines-vote-api, with the source code in the pipelines-vote-api Git repository.
  • The apply-manifests and update-deployment tasks in the pipelines-tutorial Git repository.

1.1. Prerequisites
Copy link

  • You have access to an OpenShift Container Platform cluster.
  • You have installed OpenShift Pipelines using the Red Hat OpenShift Pipelines Operator listed in the OpenShift OperatorHub. After it is installed, it is applicable to the entire cluster.
  • You have installed OpenShift Pipelines CLI.
  • You have forked the front-end pipelines-vote-ui and back-end pipelines-vote-api Git repositories using your GitHub ID, and have administrator access to these repositories.
  • Optional: You have cloned the pipelines-tutorial Git repository.

Procedure

  1. Log in to your OpenShift Container Platform cluster: 

    $ oc login -u <login> -p <password> https://openshift.example.com:6443
    Copy to Clipboard Toggle word wrap

  2. Create a project for the sample application. For this example workflow, create the pipelines-tutorial project: 

    $ oc new-project pipelines-tutorial
    Copy to Clipboard Toggle word wrap
    Note

    If you create a project with a different name, be sure to update the resource URLs used in the example with your project name.

  3. View the pipeline service account:

    Red Hat OpenShift Pipelines Operator adds and configures a service account named pipeline that has sufficient permissions to build and push an image. This service account is used by the PipelineRun object. 

    $ oc get serviceaccount pipeline
    Copy to Clipboard Toggle word wrap

1.3. Creating pipeline tasks
Copy link

Procedure

  1. Install the apply-manifests and update-deployment task resources from the pipelines-tutorial repository, which contains a list of reusable tasks for pipelines: 

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.10/01_pipeline/01_apply_manifest_task.yaml
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.10/01_pipeline/02_update_deployment_task.yaml
    Copy to Clipboard Toggle word wrap

  2. Use the tkn task list command to list the tasks you created: 

    $ tkn task list
    Copy to Clipboard Toggle word wrap

    The output verifies that the apply-manifests and update-deployment task resources were created: 

    NAME                DESCRIPTION   AGE
apply-manifests                   1 minute ago
update-deployment                 48 seconds ago
    Copy to Clipboard Toggle word wrap

  3. Use the tkn clustertasks list command to list the Operator-installed additional cluster tasks such as buildah and s2i-python:

    Note

    To use the buildah cluster task in a restricted environment, you must ensure that the Dockerfile uses an internal image stream as the base image. 

    $ tkn clustertasks list
    Copy to Clipboard Toggle word wrap

    The output lists the Operator-installed ClusterTask resources: 

    NAME                       DESCRIPTION   AGE
buildah                                  1 day ago
git-clone                                1 day ago
s2i-python                               1 day ago
tkn                                      1 day ago
    Copy to Clipboard Toggle word wrap
Important

In Red Hat OpenShift Pipelines 1.10, cluster task functionality is deprecated and is planned to be removed in a future release.

1.4. Assembling a pipeline
Copy link

A pipeline represents a CI/CD flow and is defined by the tasks to be executed. It is designed to be generic and reusable in multiple applications and environments.

A pipeline specifies how the tasks interact with each other and their order of execution using the from and runAfter parameters. It uses the workspaces field to specify one or more volumes that each task in the pipeline requires during execution.

In this section, you will create a pipeline that takes the source code of the application from GitHub, and then builds and deploys it on OpenShift Container Platform.

The pipeline performs the following tasks for the back-end application pipelines-vote-api and front-end application pipelines-vote-ui:

  • Clones the source code of the application from the Git repository by referring to the git-url and git-revision parameters.
  • Builds the container image using the buildah cluster task.
  • Pushes the image to the OpenShift image registry by referring to the image parameter.
  • Deploys the new image on OpenShift Container Platform by using the apply-manifests and update-deployment tasks.

Procedure

  1. Copy the contents of the following sample pipeline YAML file and save it: 

    apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: build-and-deploy
spec:
  workspaces:
  - name: shared-workspace
  params:
  - name: deployment-name
    type: string
    description: name of the deployment to be patched
  - name: git-url
    type: string
    description: url of the git repo for the code of deployment
  - name: git-revision
    type: string
    description: revision to be used from repo of the code for deployment
    default: "pipelines-1.10"
  - name: IMAGE
    type: string
    description: image to be built from the code
  tasks:
  - name: fetch-repository
    taskRef:
      name: git-clone
      kind: ClusterTask
    workspaces:
    - name: output
      workspace: shared-workspace
    params:
    - name: url
      value: $(params.git-url)
    - name: subdirectory
      value: ""
    - name: deleteExisting
      value: "true"
    - name: revision
      value: $(params.git-revision)
  - name: build-image
    taskRef:
      name: buildah
      kind: ClusterTask
    params:
    - name: IMAGE
      value: $(params.IMAGE)
    workspaces:
    - name: source
      workspace: shared-workspace
    runAfter:
    - fetch-repository
  - name: apply-manifests
    taskRef:
      name: apply-manifests
    workspaces:
    - name: source
      workspace: shared-workspace
    runAfter:
    - build-image
  - name: update-deployment
    taskRef:
      name: update-deployment
    params:
    - name: deployment
      value: $(params.deployment-name)
    - name: IMAGE
      value: $(params.IMAGE)
    runAfter:
    - apply-manifests
    Copy to Clipboard Toggle word wrap

    The pipeline definition abstracts away the specifics of the Git source repository and image registries. These details are added as params when a pipeline is triggered and executed.

  2. Create the pipeline: 

    $ oc create -f <pipeline-yaml-file-name.yaml>
    Copy to Clipboard Toggle word wrap

    Alternatively, you can also execute the YAML file directly from the Git repository: 

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.10/01_pipeline/04_pipeline.yaml
    Copy to Clipboard Toggle word wrap

  3. Use the tkn pipeline list command to verify that the pipeline is added to the application: 

    $ tkn pipeline list
    Copy to Clipboard Toggle word wrap

    The output verifies that the build-and-deploy pipeline was created: 

    NAME               AGE            LAST RUN   STARTED   DURATION   STATUS
build-and-deploy   1 minute ago   ---        ---       ---        ---
    Copy to Clipboard Toggle word wrap

To run OpenShift Pipelines in a disconnected cluster or a cluster provisioned in a restricted environment, ensure that either the Samples Operator is configured for a restricted network, or a cluster administrator has created a cluster with a mirrored registry.

The following procedure uses the pipelines-tutorial example to create a pipeline for an application in a restricted environment using a cluster with a mirrored registry. To ensure that the pipelines-tutorial example works in a restricted environment, you must mirror the respective builder images from the mirror registry for the front-end interface, pipelines-vote-ui; back-end interface, pipelines-vote-api; and the cli.

Procedure

  1. Mirror the builder image from the mirror registry for the front-end interface, pipelines-vote-ui.

    1. Verify that the required images tag is not imported: 

      $ oc describe imagestream python -n openshift
      Copy to Clipboard Toggle word wrap

      Example output

      Name:			python
Namespace:		openshift
[...]

3.8-ubi8 (latest)
  tagged from registry.redhat.io/ubi8/python-38:latest
    prefer registry pullthrough when referencing this tag

  Build and run Python 3.8 applications on UBI 8. For more information about using this builder image, including OpenShift considerations, see https://github.com/sclorg/s2i-python-container/blob/master/3.8/README.md.
  Tags: builder, python
  Supports: python:3.8, python
  Example Repo: https://github.com/sclorg/django-ex.git

[...]
      Copy to Clipboard Toggle word wrap

    2. Mirror the supported image tag to the private registry: 

      $ oc image mirror registry.redhat.io/ubi8/python-38:latest <mirror-registry>:<port>/ubi8/python-38
      Copy to Clipboard Toggle word wrap

    3. Import the image: 

      $ oc tag <mirror-registry>:<port>/ubi8/python-38 python:latest --scheduled -n openshift
      Copy to Clipboard Toggle word wrap

      You must periodically re-import the image. The --scheduled flag enables automatic re-import of the image.

    4. Verify that the images with the given tag have been imported: 

      $ oc describe imagestream python -n openshift
      Copy to Clipboard Toggle word wrap

      Example output

      Name:			python
Namespace:		openshift
[...]

latest
  updates automatically from registry <mirror-registry>:<port>/ubi8/python-38

  * <mirror-registry>:<port>/ubi8/python-38@sha256:3ee3c2e70251e75bfeac25c0c33356add9cc4abcbc9c51d858f39e4dc29c5f58

[...]
      Copy to Clipboard Toggle word wrap

  2. Mirror the builder image from the mirror registry for the back-end interface, pipelines-vote-api.

    1. Verify that the required images tag is not imported: 

      $ oc describe imagestream golang -n openshift
      Copy to Clipboard Toggle word wrap

      Example output

      Name:			golang
Namespace:		openshift
[...]

1.14.7-ubi8 (latest)
  tagged from registry.redhat.io/ubi8/go-toolset:1.14.7
    prefer registry pullthrough when referencing this tag

  Build and run Go applications on UBI 8. For more information about using this builder image, including OpenShift considerations, see https://github.com/sclorg/golang-container/blob/master/README.md.
  Tags: builder, golang, go
  Supports: golang
  Example Repo: https://github.com/sclorg/golang-ex.git

[...]
      Copy to Clipboard Toggle word wrap

    2. Mirror the supported image tag to the private registry: 

      $ oc image mirror registry.redhat.io/ubi8/go-toolset:1.14.7 <mirror-registry>:<port>/ubi8/go-toolset
      Copy to Clipboard Toggle word wrap

    3. Import the image: 

      $ oc tag <mirror-registry>:<port>/ubi8/go-toolset golang:latest --scheduled -n openshift
      Copy to Clipboard Toggle word wrap

      You must periodically re-import the image. The --scheduled flag enables automatic re-import of the image.

    4. Verify that the images with the given tag have been imported: 

      $ oc describe imagestream golang -n openshift
      Copy to Clipboard Toggle word wrap

      Example output

      Name:			golang
Namespace:		openshift
[...]

latest
  updates automatically from registry <mirror-registry>:<port>/ubi8/go-toolset

  * <mirror-registry>:<port>/ubi8/go-toolset@sha256:59a74d581df3a2bd63ab55f7ac106677694bf612a1fe9e7e3e1487f55c421b37

[...]
      Copy to Clipboard Toggle word wrap

  3. Mirror the builder image from the mirror registry for the cli.

    1. Verify that the required images tag is not imported: 

      $ oc describe imagestream cli -n openshift
      Copy to Clipboard Toggle word wrap

      Example output

      Name:                   cli
Namespace:              openshift
[...]

latest
  updates automatically from registry quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:65c68e8c22487375c4c6ce6f18ed5485915f2bf612e41fef6d41cbfcdb143551

  * quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:65c68e8c22487375c4c6ce6f18ed5485915f2bf612e41fef6d41cbfcdb143551

[...]
      Copy to Clipboard Toggle word wrap

    2. Mirror the supported image tag to the private registry: 

      $ oc image mirror quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:65c68e8c22487375c4c6ce6f18ed5485915f2bf612e41fef6d41cbfcdb143551 <mirror-registry>:<port>/openshift-release-dev/ocp-v4.0-art-dev:latest
      Copy to Clipboard Toggle word wrap

    3. Import the image: 

      $ oc tag <mirror-registry>:<port>/openshift-release-dev/ocp-v4.0-art-dev cli:latest --scheduled -n openshift
      Copy to Clipboard Toggle word wrap

      You must periodically re-import the image. The --scheduled flag enables automatic re-import of the image.

    4. Verify that the images with the given tag have been imported: 

      $ oc describe imagestream cli -n openshift
      Copy to Clipboard Toggle word wrap

      Example output

      Name:                   cli
Namespace:              openshift
[...]

latest
  updates automatically from registry <mirror-registry>:<port>/openshift-release-dev/ocp-v4.0-art-dev

  * <mirror-registry>:<port>/openshift-release-dev/ocp-v4.0-art-dev@sha256:65c68e8c22487375c4c6ce6f18ed5485915f2bf612e41fef6d41cbfcdb143551

[...]
      Copy to Clipboard Toggle word wrap

1.6. Running a pipeline
Copy link

A PipelineRun resource starts a pipeline and ties it to the Git and image resources that should be used for the specific invocation. It automatically creates and starts the TaskRun resources for each task in the pipeline.

Procedure

  1. Start the pipeline for the back-end application: 

    $ tkn pipeline start build-and-deploy \
    -w name=shared-workspace,volumeClaimTemplateFile=https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.10/01_pipeline/03_persistent_volume_claim.yaml \
    -p deployment-name=pipelines-vote-api \
    -p git-url=https://github.com/openshift/pipelines-vote-api.git \
    -p IMAGE='image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/pipelines-vote-api' \
    --use-param-defaults
    Copy to Clipboard Toggle word wrap

    The previous command uses a volume claim template, which creates a persistent volume claim for the pipeline execution.

  2. To track the progress of the pipeline run, enter the following command:: 

    $ tkn pipelinerun logs <pipelinerun_id> -f
    Copy to Clipboard Toggle word wrap

    The <pipelinerun_id> in the above command is the ID for the PipelineRun that was returned in the output of the previous command.

  3. Start the pipeline for the front-end application: 

    $ tkn pipeline start build-and-deploy \
    -w name=shared-workspace,volumeClaimTemplateFile=https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.10/01_pipeline/03_persistent_volume_claim.yaml \
    -p deployment-name=pipelines-vote-ui \
    -p git-url=https://github.com/openshift/pipelines-vote-ui.git \
    -p IMAGE='image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/pipelines-vote-ui' \
    --use-param-defaults
    Copy to Clipboard Toggle word wrap

  4. To track the progress of the pipeline run, enter the following command: 

    $ tkn pipelinerun logs <pipelinerun_id> -f
    Copy to Clipboard Toggle word wrap

    The <pipelinerun_id> in the above command is the ID for the PipelineRun that was returned in the output of the previous command.

  5. After a few minutes, use tkn pipelinerun list command to verify that the pipeline ran successfully by listing all the pipeline runs: 

    $ tkn pipelinerun list
    Copy to Clipboard Toggle word wrap

    The output lists the pipeline runs: 

     NAME                         STARTED      DURATION     STATUS
 build-and-deploy-run-xy7rw   1 hour ago   2 minutes    Succeeded
 build-and-deploy-run-z2rz8   1 hour ago   19 minutes   Succeeded
    Copy to Clipboard Toggle word wrap

  6. Get the application route: 

    $ oc get route pipelines-vote-ui --template='http://{{.spec.host}}'
    Copy to Clipboard Toggle word wrap

    Note the output of the previous command. You can access the application using this route.

  7. To rerun the last pipeline run, using the pipeline resources and service account of the previous pipeline, run: 

    $ tkn pipeline start build-and-deploy --last
    Copy to Clipboard Toggle word wrap

1.7. Adding triggers to a pipeline
Copy link

Triggers enable pipelines to respond to external GitHub events, such as push events and pull requests. After you assemble and start a pipeline for the application, add the TriggerBinding, TriggerTemplate, Trigger, and EventListener resources to capture the GitHub events.

Procedure

  1. Copy the content of the following sample TriggerBinding YAML file and save it: 

    apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerBinding
metadata:
  name: vote-app
spec:
  params:
  - name: git-repo-url
    value: $(body.repository.url)
  - name: git-repo-name
    value: $(body.repository.name)
  - name: git-revision
    value: $(body.head_commit.id)
    Copy to Clipboard Toggle word wrap

  2. Create the TriggerBinding resource: 

    $ oc create -f <triggerbinding-yaml-file-name.yaml>
    Copy to Clipboard Toggle word wrap

    Alternatively, you can create the TriggerBinding resource directly from the pipelines-tutorial Git repository: 

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.10/03_triggers/01_binding.yaml
    Copy to Clipboard Toggle word wrap

  3. Copy the content of the following sample TriggerTemplate YAML file and save it: 

    apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerTemplate
metadata:
  name: vote-app
spec:
  params:
  - name: git-repo-url
    description: The git repository url
  - name: git-revision
    description: The git revision
    default: pipelines-1.10
  - name: git-repo-name
    description: The name of the deployment to be created / patched

  resourcetemplates:
  - apiVersion: tekton.dev/v1beta1
    kind: PipelineRun
    metadata:
      generateName: build-deploy-$(tt.params.git-repo-name)-
    spec:
      serviceAccountName: pipeline
      pipelineRef:
        name: build-and-deploy
      params:
      - name: deployment-name
        value: $(tt.params.git-repo-name)
      - name: git-url
        value: $(tt.params.git-repo-url)
      - name: git-revision
        value: $(tt.params.git-revision)
      - name: IMAGE
        value: image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/$(tt.params.git-repo-name)
      workspaces:
      - name: shared-workspace
        volumeClaimTemplate:
          spec:
            accessModes:
              - ReadWriteOnce
            resources:
              requests:
                storage: 500Mi
    Copy to Clipboard Toggle word wrap

    The template specifies a volume claim template to create a persistent volume claim for defining the storage volume for the workspace. Therefore, you do not need to create a persistent volume claim to provide data storage.

  4. Create the TriggerTemplate resource: 

    $ oc create -f <triggertemplate-yaml-file-name.yaml>
    Copy to Clipboard Toggle word wrap

    Alternatively, you can create the TriggerTemplate resource directly from the pipelines-tutorial Git repository: 

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.10/03_triggers/02_template.yaml
    Copy to Clipboard Toggle word wrap

  5. Copy the contents of the following sample Trigger YAML file and save it: 

    apiVersion: triggers.tekton.dev/v1beta1
kind: Trigger
metadata:
  name: vote-trigger
spec:
  serviceAccountName: pipeline
  bindings:
    - ref: vote-app
  template:
    ref: vote-app
    Copy to Clipboard Toggle word wrap

  6. Create the Trigger resource: 

    $ oc create -f <trigger-yaml-file-name.yaml>
    Copy to Clipboard Toggle word wrap

    Alternatively, you can create the Trigger resource directly from the pipelines-tutorial Git repository: 

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.10/03_triggers/03_trigger.yaml
    Copy to Clipboard Toggle word wrap

  7. Copy the contents of the following sample EventListener YAML file and save it: 

    apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: vote-app
spec:
  serviceAccountName: pipeline
  triggers:
    - triggerRef: vote-trigger
    Copy to Clipboard Toggle word wrap

    Alternatively, if you have not defined a trigger custom resource, add the binding and template spec to the EventListener YAML file, instead of referring to the name of the trigger: 

    apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: vote-app
spec:
  serviceAccountName: pipeline
  triggers:
  - bindings:
    - ref: vote-app
    template:
      ref: vote-app
    Copy to Clipboard Toggle word wrap

  8. Create the EventListener resource by performing the following steps:

    • To create an EventListener resource using a secure HTTPS connection:

      1. Add a label to enable the secure HTTPS connection to the Eventlistener resource: 

        $ oc label namespace <ns-name> operator.tekton.dev/enable-annotation=enabled
        Copy to Clipboard Toggle word wrap

      2. Create the EventListener resource: 

        $ oc create -f <eventlistener-yaml-file-name.yaml>
        Copy to Clipboard Toggle word wrap

        Alternatively, you can create the EvenListener resource directly from the pipelines-tutorial Git repository: 

        $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.10/03_triggers/04_event_listener.yaml
        Copy to Clipboard Toggle word wrap

      3. Create a route with the re-encrypt TLS termination: 

        $ oc create route reencrypt --service=<svc-name> --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=<hostname>
        Copy to Clipboard Toggle word wrap

        Alternatively, you can create a re-encrypt TLS termination YAML file to create a secured route.

        Example Re-encrypt TLS Termination YAML of the Secured Route

        apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: route-passthrough-secured
        1 
        
spec:
  host: <hostname>
  to:
    kind: Service
    name: frontend
        2 
        
  tls:
    termination: reencrypt
        3 
        
    key: [as in edge termination]
    certificate: [as in edge termination]
    caCertificate: [as in edge termination]
    destinationCACertificate: |-
        4 
        
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
        Copy to Clipboard Toggle word wrap

        1 2
        The name of the object, which is limited to 63 characters.
        3
        The termination field is set to reencrypt. This is the only required tls field.
        4
        Required for re-encryption. destinationCACertificate specifies a CA certificate to validate the endpoint certificate, securing the connection from the router to the destination pods. If the service is using a service signing certificate, or the administrator has specified a default CA certificate for the router and the service has a certificate signed by that CA, this field can be omitted.

        See oc create route reencrypt --help for more options.

    • To create an EventListener resource using an insecure HTTP connection:

      1. Create the EventListener resource.

      2. Expose the EventListener service as an OpenShift Container Platform route to make it publicly accessible: 

        $ oc expose svc el-vote-app
        Copy to Clipboard Toggle word wrap
Note

You can skip this section if you want to create a basic CI/CD pipeline. However, if your deployment strategy involves multiple namespaces, you can configure event listeners to serve multiple namespaces.

To increase reusability of EvenListener objects, cluster administrators can configure and deploy them as multi-tenant event listeners that serve multiple namespaces.

Procedure

  1. Configure cluster-wide fetch permission for the event listener.

    1. Set a service account name to be used in the ClusterRoleBinding and EventListener objects. For example, el-sa.

      Example ServiceAccount.yaml

      apiVersion: v1
kind: ServiceAccount
metadata:
  name: el-sa
---
      Copy to Clipboard Toggle word wrap

    2. In the rules section of the ClusterRole.yaml file, set appropriate permissions for every event listener deployment to function cluster-wide.

      Example ClusterRole.yaml

      kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: el-sel-clusterrole
rules:
- apiGroups: ["triggers.tekton.dev"]
  resources: ["eventlisteners", "clustertriggerbindings", "clusterinterceptors", "triggerbindings", "triggertemplates", "triggers"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["configmaps", "secrets"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["impersonate"]
...
      Copy to Clipboard Toggle word wrap

    3. Configure cluster role binding with the appropriate service account name and cluster role name.

      Example ClusterRoleBinding.yaml

      apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: el-mul-clusterrolebinding
subjects:
- kind: ServiceAccount
  name: el-sa
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: el-sel-clusterrole
...
      Copy to Clipboard Toggle word wrap

  2. In the spec parameter of the event listener, add the service account name, for example el-sa. Fill the namespaceSelector parameter with names of namespaces where event listener is intended to serve.

    Example EventListener.yaml

    apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: namespace-selector-listener
spec:
  serviceAccountName: el-sa
  namespaceSelector:
    matchNames:
    - default
    - foo
...
    Copy to Clipboard Toggle word wrap

  3. Create a service account with the necessary permissions, for example foo-trigger-sa. Use it for role binding the triggers.

    Example ServiceAccount.yaml

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: foo-trigger-sa
  namespace: foo
...
    Copy to Clipboard Toggle word wrap

    Example RoleBinding.yaml

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: triggercr-rolebinding
  namespace: foo
subjects:
- kind: ServiceAccount
  name: foo-trigger-sa
  namespace: foo
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: tekton-triggers-eventlistener-roles
...
    Copy to Clipboard Toggle word wrap

  4. Create a trigger with the appropriate trigger template, trigger binding, and service account name.

    Example Trigger.yaml

    apiVersion: triggers.tekton.dev/v1beta1
kind: Trigger
metadata:
  name: trigger
  namespace: foo
spec:
  serviceAccountName: foo-trigger-sa
  interceptors:
    - ref:
        name: "github"
      params:
        - name: "secretRef"
          value:
            secretName: github-secret
            secretKey: secretToken
        - name: "eventTypes"
          value: ["push"]
  bindings:
    - ref: vote-app
  template:
    ref: vote-app
...
    Copy to Clipboard Toggle word wrap

1.9. Creating webhooks
Copy link

Webhooks are HTTP POST messages that are received by the event listeners whenever a configured event occurs in your repository. The event payload is then mapped to trigger bindings, and processed by trigger templates. The trigger templates eventually start one or more pipeline runs, leading to the creation and deployment of Kubernetes resources.

In this section, you will configure a webhook URL on your forked Git repositories pipelines-vote-ui and pipelines-vote-api. This URL points to the publicly accessible EventListener service route.

Note

Adding webhooks requires administrative privileges to the repository. If you do not have administrative access to your repository, contact your system administrator for adding webhooks.

Procedure

  1. Get the webhook URL:

    • For a secure HTTPS connection: 

      $ echo "URL: $(oc  get route el-vote-app --template='https://{{.spec.host}}')"
      Copy to Clipboard Toggle word wrap

    • For an HTTP (insecure) connection: 

      $ echo "URL: $(oc  get route el-vote-app --template='http://{{.spec.host}}')"
      Copy to Clipboard Toggle word wrap

      Note the URL obtained in the output.

  2. Configure webhooks manually on the front-end repository:

    1. Open the front-end Git repository pipelines-vote-ui in your browser.
    2. Click Settings → Webhooks → Add Webhook

    3. On the Webhooks/Add Webhook page:

      1. Enter the webhook URL from step 1 in Payload URL field
      2. Select application/json for the Content type
      3. Specify the secret in the Secret field
      4. Ensure that the Just the push event is selected
      5. Select Active
      6. Click Add Webhook
  3. Repeat step 2 for the back-end repository pipelines-vote-api.

1.10. Triggering a pipeline run
Copy link

Whenever a push event occurs in the Git repository, the configured webhook sends an event payload to the publicly exposed EventListener service route. The EventListener service of the application processes the payload, and passes it to the relevant TriggerBinding and TriggerTemplate resource pairs. The TriggerBinding resource extracts the parameters, and the TriggerTemplate resource uses these parameters and specifies the way the resources must be created. This may rebuild and redeploy the application.

In this section, you push an empty commit to the front-end pipelines-vote-ui repository, which then triggers the pipeline run.

Procedure

  1. From the terminal, clone your forked Git repository pipelines-vote-ui: 

    $ git clone git@github.com:<your GitHub ID>/pipelines-vote-ui.git -b pipelines-1.10
    Copy to Clipboard Toggle word wrap

  2. Push an empty commit: 

    $ git commit -m "empty-commit" --allow-empty && git push origin pipelines-1.10
    Copy to Clipboard Toggle word wrap

  3. Check if the pipeline run was triggered: 

    $ tkn pipelinerun list
    Copy to Clipboard Toggle word wrap

    Notice that a new pipeline run was initiated.

As a cluster administrator, to gather event listener metrics for the Triggers service in a user-defined project and display them in the OpenShift Container Platform web console, you can create a service monitor for each event listener. On receiving an HTTP request, event listeners for the Triggers service return three metrics — eventlistener_http_duration_seconds, eventlistener_event_count, and eventlistener_triggered_resources.

Prerequisites

  • You have logged in to the OpenShift Container Platform web console.
  • You have installed the Red Hat OpenShift Pipelines Operator.
  • You have enabled monitoring for user-defined projects.

Procedure

  1. For each event listener, create a service monitor. For example, to view the metrics for the github-listener event listener in the test namespace, create the following service monitor: 

    apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    app.kubernetes.io/managed-by: EventListener
    app.kubernetes.io/part-of: Triggers
    eventlistener: github-listener
  annotations:
    networkoperator.openshift.io/ignore-errors: ""
  name: el-monitor
  namespace: test
spec:
  endpoints:
    - interval: 10s
      port: http-metrics
  jobLabel: name
  namespaceSelector:
    matchNames:
      - test
  selector:
    matchLabels:
      app.kubernetes.io/managed-by: EventListener
      app.kubernetes.io/part-of: Triggers
      eventlistener: github-listener
...
    Copy to Clipboard Toggle word wrap

  2. Test the service monitor by sending a request to the event listener. For example, push an empty commit: 

    $ git commit -m "empty-commit" --allow-empty && git push origin main
    Copy to Clipboard Toggle word wrap
  3. On the OpenShift Container Platform web console, navigate to Administrator → Observe → Metrics.
  4. To view a metric, search by its name. For example, to view the details of the eventlistener_http_resources metric for the github-listener event listener, search using the eventlistener_http_resources keyword.

You can use the Administrator or Developer perspective to create and modify Pipeline, PipelineRun, and Repository objects from the Pipelines page in the OpenShift Container Platform web console. You can also use the +Add page in the Developer perspective of the web console to create CI/CD pipelines for your software delivery process.

In the Developer perspective, you can access the following options for creating pipelines from the +Add page:

  • Use the +Add → Pipelines → Pipeline builder option to create customized pipelines for your application.
  • Use the +Add → From Git option to create pipelines using pipeline templates and resources while creating an application.

After you create the pipelines for your application, you can view and visually interact with the deployed pipelines in the Pipelines view. You can also use the Topology view to interact with the pipelines created using the From Git option. You must apply custom labels to pipelines created using the Pipeline builder to see them in the Topology view.

Prerequisites

In the Developer perspective of the console, you can use the +Add → Pipeline → Pipeline builder option to:

  • Configure pipelines using either the Pipeline builder or the YAML view.
  • Construct a pipeline flow using existing tasks and cluster tasks. When you install the OpenShift Pipelines Operator, it adds reusable pipeline cluster tasks to your cluster.
Important

In Red Hat OpenShift Pipelines 1.10, cluster task functionality is deprecated and is planned to be removed in a future release.

  • Specify the type of resources required for the pipeline run, and if required, add additional parameters to the pipeline.
  • Reference these pipeline resources in each of the tasks in the pipeline as input and output resources.
  • If required, reference any additional parameters added to the pipeline in the task. The parameters for a task are prepopulated based on the specifications of the task.
  • Use the Operator-installed, reusable snippets and samples to create detailed pipelines.

Procedure

  1. In the +Add view of the Developer perspective, click the Pipeline tile to see the Pipeline builder page.

  2. Configure the pipeline using either the Pipeline builder view or the YAML view.

    Note

    The Pipeline builder view supports a limited number of fields whereas the YAML view supports all available fields. Optionally, you can also use the Operator-installed, reusable snippets and samples to create detailed pipelines.

    Figure 2.1. YAML view

    op pipeline yaml
    View larger image
    op pipeline yaml

  3. Configure your pipeline by using Pipeline builder:

    1. In the Name field, enter a unique name for the pipeline.

    2. In the Tasks section:

      1. Click Add task.
      2. Search for a task using the quick search field and select the required task from the displayed list.

      3. Click Add or Install and add. In this example, use the s2i-nodejs task.

        Note

        The search list contains all the Tekton Hub tasks and tasks available in the cluster. Also, if a task is already installed it will show Add to add the task whereas it will show Install and add to install and add the task. It will show Update and add when you add the same task with an updated version.

        • To add sequential tasks to the pipeline:

          • Click the plus icon to the right or left of the task → click Add task.
          • Search for a task using the quick search field and select the required task from the displayed list.

          • Click Add or Install and add.

            Figure 2.2. Pipeline builder

            op pipeline builder
            View larger image
            op pipeline builder

        • To add a final task:

          • Click the Add finally task → Click Add task.
          • Search for a task using the quick search field and select the required task from the displayed list.
          • Click Add or Install and add.

    3. In the Resources section, click Add Resources to specify the name and type of resources for the pipeline run. These resources are then used by the tasks in the pipeline as inputs and outputs. For this example:

      1. Add an input resource. In the Name field, enter Source, and then from the Resource Type drop-down list, select Git.

      2. Add an output resource. In the Name field, enter Img, and then from the Resource Type drop-down list, select Image.

        Note

        A red icon appears next to the task if a resource is missing.

    4. Optional: The Parameters for a task are pre-populated based on the specifications of the task. If required, use the Add Parameters link in the Parameters section to add additional parameters.
    5. In the Workspaces section, click Add workspace and enter a unique workspace name in the Name field. You can add multiple workspaces to the pipeline.

    6. In the Tasks section, click the s2i-nodejs task to see the side panel with details for the task. In the task side panel, specify the resources and parameters for the s2i-nodejs task:

      1. If required, in the Parameters section, add more parameters to the default ones, by using the $(params.<param-name>) syntax.
      2. In the Image section, enter Img as specified in the Resources section.
      3. Select a workspace from the source drop-down under Workspaces section.
    7. Add resources, parameters, and workspaces to the openshift-client task.
  4. Click Create to create and view the pipeline in the Pipeline Details page.
  5. Click the Actions drop-down menu then click Start, to see the Start Pipeline page.
  6. The Workspaces section lists the workspaces you created earlier. Use the respective drop-down to specify the volume source for your workspace. You have the following options: Empty Directory, Config Map, Secret, PersistentVolumeClaim, or VolumeClaimTemplate.

To create pipelines along with applications, use the From Git option in the Add+ view of the Developer perspective. You can view all of your available pipelines and select the pipelines you want to use to create applications while importing your code or deploying an image.

The Tekton Hub Integration is enabled by default and you can see tasks from the Tekton Hub that are supported by your cluster. Administrators can opt out of the Tekton Hub Integration and the Tekton Hub tasks will no longer be displayed. You can also check whether a webhook URL exists for a generated pipeline. Default webhooks are added for the pipelines that are created using the +Add flow and the URL is visible in the side panel of the selected resources in the Topology view.

The Pipelines view in the Developer perspective lists all the pipelines in a project, along with the following details:

  • The namespace in which the pipeline was created
  • The last pipeline run
  • The status of the tasks in the pipeline run
  • The status of the pipeline run
  • The creation time of the last pipeline run

Procedure

  1. In the Pipelines view of the Developer perspective, select a project from the Project drop-down list to see the pipelines in that project.

  2. Click the required pipeline to see the Pipeline details page.

    By default, the Details tab displays a visual representation of all the all the serial tasks, parallel tasks, finally tasks, and when expressions in the pipeline. The tasks and the finally tasks are listed in the lower right portion of the page. Click the listed Tasks and Finally tasks to view the task details.

    Figure 2.3. Pipeline details

    Pipeline details
    View larger image
    Pipeline details

  3. Optional: On the Pipeline details page, click the Metrics tab to see the following information about pipelines:

    • Pipeline Success Ratio
    • Number of Pipeline Runs
    • Pipeline Run Duration

    • Task Run Duration

      You can use this information to improve the pipeline workflow and eliminate issues early in the pipeline lifecycle.

  4. Optional: Click the YAML tab to edit the YAML file for the pipeline.

  5. Optional: Click the Pipeline Runs tab to see the completed, running, or failed runs for the pipeline.

    The Pipeline Runs tab provides details about the pipeline run, the status of the task, and a link to debug failed pipeline runs. Use the Options menu kebab to stop a running pipeline, to rerun a pipeline using the same parameters and resources as that of the previous pipeline execution, or to delete a pipeline run.

    • Click the required pipeline run to see the Pipeline Run details page. By default, the Details tab displays a visual representation of all the serial tasks, parallel tasks, finally tasks, and when expressions in the pipeline run. The results for successful runs are displayed under the Pipeline Run results pane at the bottom of the page. Additionally, you would only be able to see tasks from Tekton Hub which are supported by the cluster. While looking at a task, you can click the link beside it to jump to the task documentation.

      Note

      The Details section of the Pipeline Run Details page displays a Log Snippet of the failed pipeline run. Log Snippet provides a general error message and a snippet of the log. A link to the Logs section provides quick access to the details about the failed run.

    • On the Pipeline Run details page, click the Task Runs tab to see the completed, running, and failed runs for the task.

      The Task Runs tab provides information about the task run along with the links to its task and pod, and also the status and duration of the task run. Use the Options menu kebab to delete a task run.

    • Click the required task run to see the Task Run details page. The results for successful runs are displayed under the Task Run results pane at the bottom of the page.

      Note

      The Details section of the Task Run details page displays a Log Snippet of the failed task run. Log Snippet provides a general error message and a snippet of the log. A link to the Logs section provides quick access to the details about the failed task run.

  6. Click the Parameters tab to see the parameters defined in the pipeline. You can also add or edit additional parameters, as required.
  7. Click the Resources tab to see the resources defined in the pipeline. You can also add or edit additional resources, as required.

2.1.4. Starting pipelines from Pipelines view
Copy link

After you create a pipeline, you need to start it to execute the included tasks in the defined sequence. You can start a pipeline from the Pipelines view, the Pipeline Details page, or the Topology view.

Procedure

To start a pipeline using the Pipelines view:

  1. In the Pipelines view of the Developer perspective, click the Options kebab menu adjoining a pipeline, and select Start.

  2. The Start Pipeline dialog box displays the Git Resources and the Image Resources based on the pipeline definition.

    Note

    For pipelines created using the From Git option, the Start Pipeline dialog box also displays an APP_NAME field in the Parameters section, and all the fields in the dialog box are prepopulated by the pipeline template.

    1. If you have resources in your namespace, the Git Resources and the Image Resources fields are prepopulated with those resources. If required, use the drop-downs to select or create the required resources and customize the pipeline run instance.

  3. Optional: Modify the Advanced Options to add the credentials that authenticate the specified private Git server or the image registry.

    1. Under Advanced Options, click Show Credentials Options and select Add Secret.

    2. In the Create Source Secret section, specify the following:

      1. A unique Secret Name for the secret.
      2. In the Designated provider to be authenticated section, specify the provider to be authenticated in the Access to field, and the base Server URL.

      3. Select the Authentication Type and provide the credentials:

        • For the Authentication Type Image Registry Credentials, specify the Registry Server Address that you want to authenticate, and provide your credentials in the Username, Password, and Email fields.

          Select Add Credentials if you want to specify an additional Registry Server Address.

        • For the Authentication Type Basic Authentication, specify the values for the UserName and Password or Token fields.

        • For the Authentication Type SSH Keys, specify the value of the SSH Private Key field.

          Note

          For basic authentication and SSH authentication, you can use annotations such as:

      4. Select the check mark to add the secret.

    You can add multiple secrets based upon the number of resources in your pipeline.

  4. Click Start to start the pipeline.

  5. The Pipeline Run Details page displays the pipeline being executed. After the pipeline starts, the tasks and steps within each task are executed. You can:

    • Hover over the tasks to see the time taken to execute each step.
    • Click on a task to see the logs for each step in the task.
    • Click the Logs tab to see the logs relating to the execution sequence of the tasks. You can also expand the pane and download the logs individually or in bulk, by using the relevant button.

    • Click the Events tab to see the stream of events generated by a pipeline run.

      You can use the Task Runs, Logs, and Events tabs to assist in debugging a failed pipeline run or a failed task run.

      Figure 2.4. Pipeline run details

      Pipeline run details
      View larger image
      Pipeline run details

2.1.5. Starting pipelines from Topology view
Copy link

For pipelines created using the From Git option, you can use the Topology view to interact with pipelines after you start them:

Note

To see the pipelines created using Pipeline builder in the Topology view, customize the pipeline labels to link the pipeline with the application workload.

Procedure

  1. Click Topology in the left navigation panel.
  2. Click the application to display Pipeline Runs in the side panel.

  3. In Pipeline Runs, click Start Last Run to start a new pipeline run with the same parameters and resources as the previous one. This option is disabled if a pipeline run has not been initiated. You can also start a pipeline run when you create it.

    Figure 2.5. Pipelines in Topology view

    Pipelines in Topology view
    View larger image
    Pipelines in Topology view

In the Topology page, hover to the left of the application to see the status of its pipeline run. After a pipeline is added, a bottom left icon indicates that there is an associated pipeline.

The side panel of the application node in the Topology page displays the status of a pipeline run and you can interact with it.

  • If a pipeline run does not start automatically, the side panel displays a message that the pipeline cannot be automatically started, hence it would need to be started manually.
  • If a pipeline is created but the user has not started the pipeline, its status is not started. When the user clicks the Not started status icon, the start dialog box opens in the Topology view.
  • If the pipeline has no build or build config, the Builds section is not visible. If there is a pipeline and build config, the Builds section is visible.
  • The side panel displays a Log Snippet when a pipeline run fails on a specific task run. You can view the Log Snippet in the Pipeline Runs section, under the Resources tab. It provides a general error message and a snippet of the log. A link to the Logs section provides quick access to the details about the failed run.

2.1.7. Editing pipelines
Copy link

You can edit the pipelines in your cluster using the Developer perspective of the web console:

Procedure

  1. In the Pipelines view of the Developer perspective, select the pipeline you want to edit to see the details of the pipeline. In the Pipeline Details page, click Actions and select Edit Pipeline.

  2. On the Pipeline builder page, you can perform the following tasks:

    • Add additional tasks, parameters, or resources to the pipeline.
    • Click the task you want to modify to see the task details in the side panel and modify the required task details, such as the display name, parameters, and resources.
    • Alternatively, to delete the task, click the task, and in the side panel, click Actions and select Remove Task.
  3. Click Save to save the modified pipeline.

2.1.8. Deleting pipelines
Copy link

You can delete the pipelines in your cluster using the Developer perspective of the web console.

Procedure

  1. In the Pipelines view of the Developer perspective, click the Options kebab menu adjoining a Pipeline, and select Delete Pipeline.
  2. In the Delete Pipeline confirmation prompt, click Delete to confirm the deletion.

As a cluster administrator, you can create pipeline templates that developers can reuse when they create a pipeline on the cluster.

Prerequisites

  • You have access to an OpenShift Container Platform cluster with cluster administrator permissions, and have switched to the Administrator perspective.
  • You have installed the OpenShift Pipelines Operator in your cluster.

Procedure

  1. Navigate to the Pipelines page to view existing pipeline templates.
  2. Click the import icon icon to go to the Import YAML page.

  3. Add the YAML for your pipeline template. The template must include the following information: 

    apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
# ...
  namespace: openshift
    1 
    
  labels:
    pipeline.openshift.io/runtime: <runtime>
    2 
    
    pipeline.openshift.io/type: <pipeline-type>
    3 
    
# ...
    Copy to Clipboard Toggle word wrap
    1
    The template must be created in the openshift namespace.
    2
    The template must contain the pipeline.openshift.io/runtime label. The accepted runtime values for this label are nodejs, golang, dotnet, java, php, ruby, perl, python, nginx, and httpd.
    3
    The template must contain the pipeline.openshift.io/type: label. The accepted type values for this label are openshift, knative, and kubernetes.
  4. Click Create. After the pipeline has been created, you are taken to the Pipeline details page, where you can view information about or edit your pipeline.

As a cluster administrator, installing the Red Hat OpenShift Pipelines Operator creates variants of each default cluster task known as versioned cluster tasks (VCT) and non-versioned cluster tasks (NVCT). For example, installing the Red Hat OpenShift Pipelines Operator v1.7 creates a buildah-1-7-0 VCT and a buildah NVCT.

Both NVCT and VCT have the same metadata, behavior, and specifications, including params, workspaces, and steps. However, they behave differently when you disable them or upgrade the Operator.

Important

In Red Hat OpenShift Pipelines 1.10, cluster task functionality is deprecated and is planned to be removed in a future release.

Non-versioned and versioned cluster tasks have different naming conventions. And, the Red Hat OpenShift Pipelines Operator upgrades them differently.

Expand
Table 3.1. Differences between non-versioned and versioned cluster tasks
 Non-versioned cluster taskVersioned cluster task

Nomenclature

The NVCT only contains the name of the cluster task. For example, the name of the NVCT of Buildah installed with Operator v1.7 is buildah.

The VCT contains the name of the cluster task, followed by the version as a suffix. For example, the name of the VCT of Buildah installed with Operator v1.7 is buildah-1-7-0.

Upgrade

When you upgrade the Operator, it updates the non-versioned cluster task with the latest changes. The name of the NVCT remains unchanged.

Upgrading the Operator installs the latest version of the VCT and retains the earlier version. The latest version of a VCT corresponds to the upgraded Operator. For example, installing Operator 1.7 installs buildah-1-7-0 and retains buildah-1-6-0.

Before adopting non-versioned or versioned cluster tasks as a standard in production environments, cluster administrators might consider their advantages and disadvantages.

Expand
Table 3.2. Advantages and disadvantages of non-versioned and versioned cluster tasks
Cluster taskAdvantagesDisadvantages

Non-versioned cluster task (NVCT)

  • If you prefer deploying pipelines with the latest updates and bug fixes, use the NVCT.
  • Upgrading the Operator upgrades the non-versioned cluster tasks, which consume fewer resources than multiple versioned cluster tasks.

If you deploy pipelines that use NVCT, they might break after an Operator upgrade if the automatically upgraded cluster tasks are not backward-compatible.

Versioned cluster task (VCT)

  • If you prefer stable pipelines in production, use the VCT.
  • The earlier version is retained on the cluster even after the later version of a cluster task is installed. You can continue using the earlier cluster tasks.
  • If you continue using an earlier version of a cluster task, you might miss the latest features and critical security updates.
  • The earlier versions of cluster tasks that are not operational consume cluster resources.
  • * After it is upgraded, the Operator cannot manage the earlier VCT. You can delete the earlier VCT manually by using the oc delete clustertask command, but you cannot restore it.

As a cluster administrator, you can disable cluster tasks that the OpenShift Pipelines Operator installed.

Procedure

  1. To delete all non-versioned cluster tasks and latest versioned cluster tasks, edit the TektonConfig custom resource definition (CRD) and set the clusterTasks parameter in spec.addon.params to false.

    Example TektonConfig CR

    apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  params:
  - name: createRbacResource
    value: "false"
  profile: all
  targetNamespace: openshift-pipelines
  addon:
    params:
    - name: clusterTasks
      value: "false"
...
    Copy to Clipboard Toggle word wrap

    When you disable cluster tasks, the Operator removes all the non-versioned cluster tasks and only the latest version of the versioned cluster tasks from the cluster.

    Note

    Re-enabling cluster tasks installs the non-versioned cluster tasks.

  2. Optional: To delete earlier versions of the versioned cluster tasks, use any one of the following methods:

    1. To delete individual earlier versioned cluster tasks, use the oc delete clustertask command followed by the versioned cluster task name. For example: 

      $ oc delete clustertask buildah-1-6-0
      Copy to Clipboard Toggle word wrap

    2. To delete all versioned cluster tasks created by an old version of the Operator, you can delete the corresponding installer set. For example: 

      $ oc delete tektoninstallerset versioned-clustertask-1-6-k98as
      Copy to Clipboard Toggle word wrap
      Important

      If you delete an old versioned cluster task, you cannot restore it. You can only restore versioned and non-versioned cluster tasks that the current version of the Operator has created.

Legal Notice
Copy link

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat