Creating CI/CD pipelines

Procedure

1. Log in to your OpenShift Container Platform cluster:

   Copy to Clipboard Toggle word wrap

   $ oc login -u <login> -p <password> https://openshift.example.com:6443

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

   Copy to Clipboard Toggle word wrap

   $ oc new-project pipelines-tutorial

   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.

   Copy to Clipboard Toggle word wrap

   $ oc get serviceaccount pipeline

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:

   Copy to Clipboard Toggle word wrap

   $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.12/01_pipeline/01_apply_manifest_task.yaml
   $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.12/01_pipeline/02_update_deployment_task.yaml

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

   Copy to Clipboard Toggle word wrap

   $ tkn task list

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

   Copy to Clipboard Toggle word wrap

   NAME                DESCRIPTION   AGE
   apply-manifests                   1 minute ago
   update-deployment                 48 seconds ago

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.

   Copy to Clipboard Toggle word wrap

   $ tkn clustertasks list

   The output lists the Operator-installed ClusterTask resources:

   Copy to Clipboard Toggle word wrap

   NAME                       DESCRIPTION   AGE
   buildah                                  1 day ago
   git-clone                                1 day ago
   s2i-python                               1 day ago
   tkn                                      1 day ago

Procedure

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

   Copy to Clipboard Toggle word wrap

   apiVersion: tekton.dev/v1
   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.12"
     - 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

   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:

   Copy to Clipboard Toggle word wrap

   $ oc create -f <pipeline-yaml-file-name.yaml>

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

   Copy to Clipboard Toggle word wrap

   $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.12/01_pipeline/04_pipeline.yaml

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

   Copy to Clipboard Toggle word wrap

   $ tkn pipeline list

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

   Copy to Clipboard Toggle word wrap

   NAME               AGE            LAST RUN   STARTED   DURATION   STATUS
   build-and-deploy   1 minute ago   ---        ---       ---        ---

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:

      Copy to Clipboard Toggle word wrap

      $ oc describe imagestream python -n openshift

      Example output

      Copy to Clipboard Toggle word wrap

      Name:			python
      Namespace:		openshift
      [...]
      
      3.8-ubi9 (latest)
        tagged from registry.redhat.io/ubi9/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
      
      [...]

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

      Copy to Clipboard Toggle word wrap

      $ oc image mirror registry.redhat.io/ubi9/python-39:latest <mirror-registry>:<port>/ubi9/python-39

   3. Import the image:

      Copy to Clipboard Toggle word wrap

      $ oc tag <mirror-registry>:<port>/ubi9/python-39 python:latest --scheduled -n openshift

      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:

      Copy to Clipboard Toggle word wrap

      $ oc describe imagestream python -n openshift

      Example output

      Copy to Clipboard Toggle word wrap

      Name:			python
      Namespace:		openshift
      [...]
      
      latest
        updates automatically from registry  <mirror-registry>:<port>/ubi9/python-39
      
        *  <mirror-registry>:<port>/ubi9/python-39@sha256:3ee...
      
      [...]

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:

      Copy to Clipboard Toggle word wrap

      $ oc describe imagestream golang -n openshift

      Example output

      Copy to Clipboard Toggle word wrap

      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
      
      [...]

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

      Copy to Clipboard Toggle word wrap

      $ oc image mirror registry.redhat.io/ubi9/go-toolset:latest <mirror-registry>:<port>/ubi9/go-toolset

   3. Import the image:

      Copy to Clipboard Toggle word wrap

      $ oc tag <mirror-registry>:<port>/ubi9/go-toolset golang:latest --scheduled -n openshift

      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:

      Copy to Clipboard Toggle word wrap

      $ oc describe imagestream golang -n openshift

      Example output

      Copy to Clipboard Toggle word wrap

      Name:			golang
      Namespace:		openshift
      [...]
      
      latest
        updates automatically from registry <mirror-registry>:<port>/ubi9/go-toolset
      
        * <mirror-registry>:<port>/ubi9/go-toolset@sha256:59a74d581df3a2bd63ab55f7ac106677694bf612a1fe9e7e3e1487f55c421b37
      
      [...]

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

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

      Copy to Clipboard Toggle word wrap

      $ oc describe imagestream cli -n openshift

      Example output

      Copy to Clipboard Toggle word wrap

      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
      
      [...]

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

      Copy to Clipboard Toggle word wrap

      $ 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

   3. Import the image:

      Copy to Clipboard Toggle word wrap

      $ oc tag <mirror-registry>:<port>/openshift-release-dev/ocp-v4.0-art-dev cli:latest --scheduled -n openshift

      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:

      Copy to Clipboard Toggle word wrap

      $ oc describe imagestream cli -n openshift

      Example output

      Copy to Clipboard Toggle word wrap

      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
      
      [...]

Procedure

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

   Copy to Clipboard Toggle word wrap

   $ tkn pipeline start build-and-deploy \
       -w name=shared-workspace,volumeClaimTemplateFile=https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.12/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

   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::

   Copy to Clipboard Toggle word wrap

   $ tkn pipelinerun logs <pipelinerun_id> -f

   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:

   Copy to Clipboard Toggle word wrap

   $ tkn pipeline start build-and-deploy \
       -w name=shared-workspace,volumeClaimTemplateFile=https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.12/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

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

   Copy to Clipboard Toggle word wrap

   $ tkn pipelinerun logs <pipelinerun_id> -f

   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:

   Copy to Clipboard Toggle word wrap

   $ tkn pipelinerun list

   The output lists the pipeline runs:

   Copy to Clipboard Toggle word wrap

    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

6. Get the application route:

   Copy to Clipboard Toggle word wrap

   $ oc get route pipelines-vote-ui --template='http://{{.spec.host}}'

   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:

   Copy to Clipboard Toggle word wrap

   $ tkn pipeline start build-and-deploy --last

Procedure

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

   Copy to Clipboard Toggle word wrap

   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)

2. Create the TriggerBinding resource:

   Copy to Clipboard Toggle word wrap

   $ oc create -f <triggerbinding-yaml-file-name.yaml>

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

   Copy to Clipboard Toggle word wrap

   $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.12/03_triggers/01_binding.yaml

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

   Copy to Clipboard Toggle word wrap

   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.12
     - name: git-repo-name
       description: The name of the deployment to be created / patched
   
     resourcetemplates:
     - apiVersion: tekton.dev/v1
       kind: PipelineRun
       metadata:
         generateName: build-deploy-$(tt.params.git-repo-name)-
       spec:
         taskRunTemplate:
           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

   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:

   Copy to Clipboard Toggle word wrap

   $ oc create -f <triggertemplate-yaml-file-name.yaml>

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

   Copy to Clipboard Toggle word wrap

   $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.12/03_triggers/02_template.yaml

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

   Copy to Clipboard Toggle word wrap

   apiVersion: triggers.tekton.dev/v1beta1
   kind: Trigger
   metadata:
     name: vote-trigger
   spec:
     taskRunTemplate:
       serviceAccountName: pipeline
     bindings:
       - ref: vote-app
     template:
       ref: vote-app

6. Create the Trigger resource:

   Copy to Clipboard Toggle word wrap

   $ oc create -f <trigger-yaml-file-name.yaml>

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

   Copy to Clipboard Toggle word wrap

   $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.12/03_triggers/03_trigger.yaml

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

   Copy to Clipboard Toggle word wrap

   apiVersion: triggers.tekton.dev/v1beta1
   kind: EventListener
   metadata:
     name: vote-app
   spec:
     taskRunTemplate:
       serviceAccountName: pipeline
     triggers:
       - triggerRef: vote-trigger

   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:

   Copy to Clipboard Toggle word wrap

   apiVersion: triggers.tekton.dev/v1beta1
   kind: EventListener
   metadata:
     name: vote-app
   spec:
     taskRunTemplate:
       serviceAccountName: pipeline
     triggers:
     - bindings:
       - ref: vote-app
       template:
         ref: vote-app

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:

        Copy to Clipboard Toggle word wrap

        $ oc label namespace <ns-name> operator.tekton.dev/enable-annotation=enabled

     2. Create the EventListener resource:

        Copy to Clipboard Toggle word wrap

        $ oc create -f <eventlistener-yaml-file-name.yaml>

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

        Copy to Clipboard Toggle word wrap

        $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.12/03_triggers/04_event_listener.yaml

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

        Copy to Clipboard Toggle word wrap

        $ oc create route reencrypt --service=<svc-name> --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=<hostname>

        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

        Copy to Clipboard Toggle word wrap

        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-----

        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:

        Copy to Clipboard Toggle word wrap

        $ oc expose svc el-vote-app

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

      Copy to Clipboard Toggle word wrap

      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: el-sa
      ---

   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

      Copy to Clipboard Toggle word wrap

      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"]
      ...

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

      Example ClusterRoleBinding.yaml

      Copy to Clipboard Toggle word wrap

      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
      ...

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

   Copy to Clipboard Toggle word wrap

   apiVersion: triggers.tekton.dev/v1beta1
   kind: EventListener
   metadata:
     name: namespace-selector-listener
   spec:
     taskRunTemplate:
       serviceAccountName: el-sa
     namespaceSelector:
       matchNames:
       - default
       - foo
   ...

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

   Example ServiceAccount.yaml

   Copy to Clipboard Toggle word wrap

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: foo-trigger-sa
     namespace: foo
   ...

   Example RoleBinding.yaml

   Copy to Clipboard Toggle word wrap

   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
   ...

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

   Example Trigger.yaml

   Copy to Clipboard Toggle word wrap

   apiVersion: triggers.tekton.dev/v1beta1
   kind: Trigger
   metadata:
     name: trigger
     namespace: foo
   spec:
     taskRunTemplate:
       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
   ...

Procedure

1. Get the webhook URL:

   • For a secure HTTPS connection:

     Copy to Clipboard Toggle word wrap

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

   • For an HTTP (insecure) connection:

     Copy to Clipboard Toggle word wrap

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

     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.

Procedure

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

   Copy to Clipboard Toggle word wrap

   $ git clone git@github.com:<your GitHub ID>/pipelines-vote-ui.git -b pipelines-1.12

2. Push an empty commit:

   Copy to Clipboard Toggle word wrap

   $ git commit -m "empty-commit" --allow-empty && git push origin pipelines-1.12

3. Check if the pipeline run was triggered:

   Copy to Clipboard Toggle word wrap

   $ tkn pipelinerun list

   Notice that a new pipeline run was initiated.

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:

   Copy to Clipboard Toggle word wrap

   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
   ...

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

   Copy to Clipboard Toggle word wrap

   $ git commit -m "empty-commit" --allow-empty && git push origin main

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.

Procedure

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

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

   Copy to Clipboard Toggle word wrap

   apiVersion: tekton.dev/v1
   kind: Pipeline
   metadata:
   # ...
     namespace: openshift 

   1

   
     labels:
       pipeline.openshift.io/runtime: <runtime> 

   2

   
       pipeline.openshift.io/type: <pipeline-type> 

   3

   
   # ...

   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.

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

   Copy to Clipboard Toggle word wrap

   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"
   ...

   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:

      Copy to Clipboard Toggle word wrap

      $ oc delete clustertask buildah-1-6-0

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

      Copy to Clipboard Toggle word wrap

      $ oc delete tektoninstallerset versioned-clustertask-1-6-k98as

      Caution

      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.