Chapter 4. Pipelines

Procedure

1. In the Administrator perspective of the web console, navigate to Operators OperatorHub.
2. Use the Filter by keyword box to search for Red Hat OpenShift Pipelines Operator in the catalog. Click the Red Hat OpenShift Pipelines Operator tile.
3. Read the brief description about the Operator on the Red Hat OpenShift Pipelines Operator page. Click Install.

4. On the Install Operator page:

   1. Select All namespaces on the cluster (default) for the Installation Mode. This mode installs the Operator in the default openshift-operators namespace, which enables the Operator to watch and be made available to all namespaces in the cluster.
   2. Select Automatic for the Approval Strategy. This ensures that the future upgrades to the Operator are handled automatically by the Operator Lifecycle Manager (OLM). If you select the Manual approval strategy, OLM creates an update request. As a cluster administrator, you must then manually approve the OLM update request to update the Operator to the new version.

   3. Select an Update Channel.

      • The stable channel enables installation of the latest stable and supported release of the Red Hat OpenShift Pipelines Operator.
      • The preview channel enables installation of the latest preview version of the Red Hat OpenShift Pipelines Operator, which may contain features that are not yet available from the stable channel and is not supported.

5. Click Install. You will see the Operator listed on the Installed Operators page.

   Note

   The Operator is installed automatically into the openshift-operators namespace.

6. Verify that the Status is set to Succeeded Up to date to confirm successful installation of Red Hat OpenShift Pipelines Operator.

Procedure

1. Create a Subscription object YAML file to subscribe a namespace to the Red Hat OpenShift Pipelines Operator, for example, sub.yaml:

   Example Subscription

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: openshift-pipelines-operator
     namespace: openshift-operators
   spec:
     channel:  <channel name> 1
     name: openshift-pipelines-operator-rh 2
     source: redhat-operators 3
     sourceNamespace: openshift-marketplace 4

   1

   Specify the channel name from where you want to subscribe the Operator

   2

   Name of the Operator to subscribe to.

   3

   Name of the CatalogSource that provides the Operator.

   4

   Namespace of the CatalogSource. Use openshift-marketplace for the default OperatorHub CatalogSources.

2. Create the Subscription object:

   $ oc apply -f sub.yaml

   The Red Hat OpenShift Pipelines Operator is now installed in the default target namespace openshift-operators.

Procedure

1. In the Administrator perspective of the web console, navigate to Administration Custom Resource Definition.
2. Type config.operator.tekton.dev in the Filter by name box to search for the Red Hat OpenShift Pipelines Operator CRs.
3. Click CRD Config to see the Custom Resource Definition Details page.

4. Click the Actions drop-down menu and select Delete Custom Resource Definition.

   Note

   Deleting the CRs will delete the Red Hat OpenShift Pipelines components, and all the Tasks and Pipelines on the cluster will be lost.

5. Click Delete to confirm the deletion of the CRs.

Procedure

1. From the Operators OperatorHub page, use the Filter by keyword box to search for Red Hat OpenShift Pipelines Operator.
2. Click the OpenShift Pipelines Operator tile. The Operator tile indicates it is installed.
3. In the OpenShift Pipelines Operator descriptor page, click Uninstall.

Procedure

1. Log in to your OpenShift Container Platform cluster:

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

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

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

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

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

   $ tkn task list

   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

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

   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

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

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

   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.5/01_pipeline/04_pipeline.yaml

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

   $ tkn pipeline list

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

   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:

      $ oc describe imagestream python -n openshift

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

   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

   3. Import the image:

      $ oc tag <mirror-registry>:<port>/ubi8/python-38 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:

      $ oc describe imagestream python -n openshift

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

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

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

   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

   3. Import the image:

      $ oc tag <mirror-registry>:<port>/ubi8/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:

      $ oc describe imagestream golang -n openshift

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

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

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

   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

   3. Import the image:

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

      $ oc describe imagestream cli -n openshift

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

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.5/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::

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

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

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

   $ tkn pipelinerun list

   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

6. Get the application route:

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

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

Procedure

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

   apiVersion: triggers.tekton.dev/v1alpha1
   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:

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

   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.5/03_triggers/01_binding.yaml

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

   apiVersion: triggers.tekton.dev/v1alpha1
   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.5
     - 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

   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>

   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.5/03_triggers/02_template.yaml

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

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

6. Create the Trigger resource:

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

   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.5/03_triggers/03_trigger.yaml

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

   apiVersion: triggers.tekton.dev/v1alpha1
   kind: EventListener
   metadata:
     name: vote-app
   spec:
     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:

   apiVersion: triggers.tekton.dev/v1alpha1
   kind: EventListener
   metadata:
     name: vote-app
   spec:
     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:

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

     2. Create the EventListener resource:

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

        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.5/03_triggers/04_event_listener.yaml

     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>

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

        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

Procedure

1. Get the webhook URL:

   • For a secure HTTPS connection:

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

   • For an HTTP (insecure) connection:

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

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

2. Push an empty commit:

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

3. Check if the pipeline run was triggered:

   $ tkn pipelinerun list

   Notice that a new pipeline run was initiated.

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 4.1. YAML view

   

   Configure your pipeline using the Pipeline Builder:

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

   2. In the Tasks section, select a task from the Select Task list to add a task to the pipeline. In this example, use the s2i-nodejs task.

      • To add sequential tasks to the pipeline, click the plus icon to the right or left of the task, and from the Select Task list, select the task you want to add to the pipeline. For this example, use the plus icon to the right of the s2i-nodejs task to add an openshift-client task.

      • To add a parallel task to the existing task, click the plus icon displayed next to the task, and from the Select Task list, select the parallel task you want to add to the pipeline.

        Figure 4.2. Pipeline Builder

        

   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.
3. Click Create to create and view the pipeline in the Pipeline Details page.
4. Click the Actions drop-down menu then click Start, to see the Start Pipeline page.
5. 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.

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

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

Procedure

1. Log in to the OpenShift Container Platform web console as a cluster administrator.

2. In the Administrator perspective, use the left navigation panel to go to the Pipelines section.

   1. From the Project drop-down, select the openshift project. This ensures that the subsequent steps are performed in the openshift namespace.

   2. From the list of available pipelines, select a pipeline that is appropriate for building and deploying your application. For example, if your application requires a node.js runtime environment, select the s2i-nodejs pipeline.

      Note

      Do not edit the default pipeline template. It may become incompatible with the UI and the back-end.

   3. Under the YAML tab of the selected pipeline, click Download and save the YAML file to your local machine. If your custom configuration file fails, you can use this copy to restore a working configuration.

3. Disable (delete) the default pipeline templates:

   1. Use the left navigation panel to go to Operators Installed Operators.
   2. Click Red Hat OpenShift Pipelines Tekton Configuration tab config YAML tab.

   3. To disable (delete) the default pipeline templates in the openshift namespace, set the pipelineTemplates parameter to false in the TektonConfig custom resource YAML, and save it.

      apiVersion: operator.tekton.dev/v1alpha1
      kind: TektonConfig
      metadata:
        name: config
      spec:
      profile: all
      targetNamespace: openshift-pipelines
      addon:
        params:
        - name: clusterTasks
          value: "true"
        - name: pipelineTemplates
          value: "false"
      ...

      Note

      If you manually delete the default pipeline templates, the operator will restore the defaults during an upgrade.

      Warning

      As a cluster admin, you can disable installation of the default pipeline templates in the operator configuration. However, such a configuration will disable (delete) all default pipeline templates, and not only the one you want to customize.

4. Create a custom pipeline template:

   1. Use the left navigation panel to go to the Pipelines section.
   2. From the Create drop-down, select Pipeline.

   3. Create the required pipeline in the openshift namespace. Give it a different name than the default one (for example, custom-nodejs). You can use the downloaded default pipeline template as a starting point and customize it.

      Note

      Because openshift is the default namespace used by the operator-installed pipeline templates, you must create the custom pipeline template in the openshift namespace. When an application uses a pipeline template, the template is automatically copied to the respective project’s namespace.

   4. Under the Details tab of the created pipeline, ensure that the Labels in the custom template match the labels in the default pipeline. The custom pipeline template must have the correct labels for the runtime, type, and strategy of the application. For example, the required labels for a node.js application deployed on OpenShift Container Platform are as follows:

      ...
      pipeline.openshift.io/runtime: nodejs
      pipeline.openshift.io/type: openshift
      ...

      Note

      You can use only one pipeline template for each combination of runtime environment and deployment type.

5. In the Developer perspective, use the +Add Git Repository From Git option to select the kind of application you want to create and deploy. Based on the required runtime and type of the application, your custom template is automatically selected.

1. In the Pipelines view of the Developer perspective, click the Options 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:

           • tekton.dev/git-0: https://github.com
           • tekton.dev/git-1: https://gitlab.com.
      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 4.4. Pipeline run details

     

6. 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 the Pipeline Builder in the Topology view, customize the pipeline labels to link the pipeline with the application workload.

   1. On the left navigation panel, click Topology, and click on the application to see the pipeline runs listed in the side panel.

   2. In the Pipeline Runs section, 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.

      Figure 4.5. Pipelines in Topology view

      

   3. In the Topology page, hover to the left of the application to see the status of the pipeline run for the application.

      Note

      The side panel of the application node in the Topology page 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. 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.

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. In the Pipeline Builder page:

   • You can add additional Tasks, parameters, or resources to the Pipeline.
   • You can 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.

Procedure

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

Procedure

1. Define a custom SCC with the fsGroup.type parameter set to RunAsAny:

   Example: Custom SCC

   apiVersion: security.openshift.io/v1
   kind: SecurityContextConstraints
   metadata:
     annotations:
       kubernetes.io/description: my-scc is a close replica of anyuid scc. pipelines-scc has fsGroup - RunAsAny.
     name: my-scc
   allowHostDirVolumePlugin: false
   allowHostIPC: false
   allowHostNetwork: false
   allowHostPID: false
   allowHostPorts: false
   allowPrivilegeEscalation: true
   allowPrivilegedContainer: false
   allowedCapabilities: null
   defaultAddCapabilities: null
   fsGroup:
     type: RunAsAny
   groups:
   - system:cluster-admins
   priority: 10
   readOnlyRootFilesystem: false
   requiredDropCapabilities:
   - MKNOD
   runAsUser:
     type: RunAsAny
   seLinuxContext:
     type: MustRunAs
   supplementalGroups:
     type: RunAsAny
   volumes:
   - configMap
   - downwardAPI
   - emptyDir
   - persistentVolumeClaim
   - projected
   - secret

2. Create the custom SCC:

   Example: Create the my-scc SCC

   $ oc create -f my-scc.yaml

3. Create a custom service account:

   Example: Create a fsgroup-runasany service account

   $ oc create serviceaccount fsgroup-runasany

4. Associate the custom SCC with the custom service account:

   Example: Associate the my-scc SCC with the fsgroup-runasany service account

   $ oc adm policy add-scc-to-user my-scc -z fsgroup-runasany

   If you want to use the custom service account for privileged tasks, you can associate the privileged SCC with the custom service account by running the following command:

   Example: Associate the privileged SCC with the fsgroup-runasany service account

   $ oc adm policy add-scc-to-user privileged -z fsgroup-runasany

5. Use the custom service account in the pipeline run and task run:

   Example: Pipeline run YAML with fsgroup-runasany custom service account

   apiVersion: tekton.dev/v1beta1
   kind: PipelineRun
   metadata:
     name: <pipeline-run-name>
   spec:
     pipelineRef:
       name: <pipeline-cluster-task-name>
     serviceAccountName: 'fsgroup-runasany'

   Example: Task run YAML with fsgroup-runasany custom service account

   apiVersion: tekton.dev/v1beta1
   kind: TaskRun
   metadata:
     name: <task-run-name>
   spec:
     taskRef:
       name: <cluster-task-name>
     serviceAccountName: 'fsgroup-runasany'

Procedure

1. Create the TriggerBinding resource from the YAML file available in the pipelines-tutorial repository:

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

2. Create the TriggerTemplate resource from the YAML file available in the pipelines-tutorial repository:

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

3. Create the Trigger resource directly from the pipelines-tutorial repository:

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

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

   2. Create the EventListener resource from the YAML file available in the pipelines-tutorial repository:

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

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

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

Procedure

1. In the secret.yaml file, specify the username and password or GitHub personal access token to access the target Git repository.

   apiVersion: v1
   kind: Secret
   metadata:
     name: basic-user-pass 1
     annotations:
       tekton.dev/git-0: https://github.com
   type: kubernetes.io/basic-auth
   stringData:
     username: 2
     password: 3

   1

   Name of the secret. In this example, basic-user-pass.

   2

   Username for the Git repository.

   3

   Password for the Git repository.

2. In the serviceaccount.yaml file, associate the secret with the appropriate service account.

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: build-bot 1
   secrets:
     - name: basic-user-pass 2

   1

   Name of the service account. In this example, build-bot.

   2

   Name of the secret. In this example, basic-user-pass.

3. In the run.yaml file, associate the service account with a task run or a pipeline run.

   • Associate the service account with a task run:

     apiVersion: tekton.dev/v1beta1
     kind: TaskRun
     metadata:
       name: build-push-task-run-2 1
     spec:
       serviceAccountName: build-bot 2
       taskRef:
         name: build-push 3

     1

     Name of the task run. In this example, build-push-task-run-2.

     2

     Name of the service account. In this example, build-bot.

     3

     Name of the task. In this example, build-push.

   • Associate the service account with a PipelineRun resource:

     apiVersion: tekton.dev/v1beta1
     kind: PipelineRun
     metadata:
       name: demo-pipeline 1
       namespace: default
     spec:
       serviceAccountName: build-bot 2
       pipelineRef:
         name: demo-pipeline 3

     1

     Name of the pipeline run. In this example, demo-pipeline.

     2

     Name of the service account. In this example, build-bot.

     3

     Name of the pipeline. In this example, demo-pipeline.

4. Apply the changes.

   $ kubectl apply --filename secret.yaml,serviceaccount.yaml,run.yaml

Procedure

1. Generate an SSH private key, or copy an existing private key, which is usually available in the ~/.ssh/id_rsa file.

2. In the secret.yaml file, set the value of ssh-privatekey to the name of the SSH private key file, and set the value of known_hosts to the name of the known hosts file.

   apiVersion: v1
   kind: Secret
   metadata:
     name: ssh-key 1
     annotations:
       tekton.dev/git-0: github.com
   type: kubernetes.io/ssh-auth
   stringData:
     ssh-privatekey: 2
     known_hosts: 3

   1

   Name of the secret containing the SSH private key. In this example, ssh-key.

   2

   Name of the file containing the SSH private key string.

   3

   Name of the file containing a list of known hosts.

   Caution

   If you omit the private key, Pipelines accepts the public key of any server.

3. Optional: To specify a custom SSH port, add :<port number> to the end of the annotation value. For example, tekton.dev/git-0: github.com:2222.

4. In the serviceaccount.yaml file, associate the ssh-key secret with the build-bot service account.

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: build-bot 1
   secrets:
     - name: ssh-key 2

   1

   Name of the service account. In this example, build-bot.

   2

   Name of the secret containing the SSH private key. In this example, ssh-key.

5. In the run.yaml file, associate the service account with a task run or a pipeline run.

   • Associate the service account with a task run:

     apiVersion: tekton.dev/v1beta1
     kind: TaskRun
     metadata:
       name: build-push-task-run-2 1
     spec:
       serviceAccountName: build-bot 2
       taskRef:
         name: build-push 3

     1

     Name of the task run. In this example, build-push-task-run-2.

     2

     Name of the service account. In this example, build-bot.

     3

     Name of the task. In this example, build-push.

   • Associate the service account with a pipeline run:

     apiVersion: tekton.dev/v1beta1
     kind: PipelineRun
     metadata:
       name: demo-pipeline 1
       namespace: default
     spec:
       serviceAccountName: build-bot 2
       pipelineRef:
         name: demo-pipeline 3

     1

     Name of the pipeline run. In this example, demo-pipeline.

     2

     Name of the service account. In this example, build-bot.

     3

     Name of the pipeline. In this example, demo-pipeline.

6. Apply the changes.

   $ kubectl apply --filename secret.yaml,serviceaccount.yaml,run.yaml

Procedure

1. Log in to OpenShift Container Platform web console as a cluster administrator.
2. In the top right of the menu bar, click the grid icon Observability Logging. The Kibana web console is displayed.

3. Create an index pattern:

   1. On the left navigation panel of the Kibana web console, click Management.
   2. Click Create index pattern.
   3. Under Step 1 of 2: Define index pattern Index pattern, enter a * pattern and click Next Step.
   4. Under Step 2 of 2: Configure settings Time filter field name, select @timestamp from the drop-down menu, and click Create index pattern.

4. Add a filter:

   1. On the left navigation panel of the Kibana web console, click Discover.

   2. Click Add a filter + Edit Query DSL.

      Note
      • For each of the example filters that follows, edit the query and click Save.
      • The filters are applied one after another.

      1. Filter the containers related to pipelines:

         Example query to filter pipelines containers

         {
           "query": {
         	"match": {
           	"kubernetes.flat_labels": {
             	"query": "app_kubernetes_io/managed-by=tekton-pipelines",
             	"type": "phrase"
           	}
         	}
           }
         }

      2. Filter all containers that are not place-tools container. As an illustration of using the graphical drop-down menus instead of editing the query DSL, consider the following approach:

         Figure 4.6. Example of filtering using the drop-down fields

         

      3. Filter pipelinerun in labels for highlighting:

         Example query to filter pipelinerun in labels for highlighting

         {
           "query": {
         	"match": {
           	"kubernetes.flat_labels": {
             	"query": "tekton_dev/pipelineRun=",
             	"type": "phrase"
           	}
         	}
           }
         }

      4. Filter pipeline in labels for highlighting:

         Example query to filter pipeline in labels for highlighting

         {
           "query": {
         	"match": {
           	"kubernetes.flat_labels": {
             	"query": "tekton_dev/pipeline=",
             	"type": "phrase"
           	}
         	}
           }
         }

   3. From the Available fields list, select the following fields:

      • kubernetes.flat_labels

      • message

        Ensure that the selected fields are displayed under the Selected fields list.

   4. The logs are displayed under the message field.

      Figure 4.7. Filtered messages