Installing and configuring

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 available to all namespaces in the cluster.
   2. Select Automatic for the Approval Strategy. This ensures that the Operator Lifecycle Manager (OLM) automatically handles future upgrades to the Operator. 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 latest channel enables installation of the most recent stable version of the Red Hat OpenShift Pipelines Operator. Currently, it is the default channel for installing the Red Hat OpenShift Pipelines Operator.

      • To install a specific version of the Red Hat OpenShift Pipelines Operator, cluster administrators can use the corresponding pipelines-<version> channel. For example, to install the Red Hat OpenShift Pipelines Operator version 1.8.x, you can use the pipelines-1.8 channel.

        Note

        Starting with OpenShift Container Platform 4.11, the preview and stable channels for installing and upgrading the Red Hat OpenShift Pipelines Operator are not available. However, in OpenShift Container Platform 4.10 and earlier versions, you can use the preview and stable channels for installing and upgrading the Operator.

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

   Note

   The Operator installs automatically into the openshift-operators namespace.

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

   Warning

   The success status might show as Succeeded Up to date even if installation of other components is in-progress. Therefore, it is important to verify the installation manually in the terminal.

7. Verify that the Red Hat OpenShift Pipelines Operator installed all components successfully. Login to the cluster on the terminal, and run the following command:

   $ oc get tektonconfig config

   Example output

   NAME     VERSION                          READY   REASON
   config   1.21.0     True

   If the READY condition is True, the Operator and its components installed successfully.

   Additionally, check the components' versions by running the following command:

   $ oc get tektonpipeline,tektontrigger,tektonchain,tektonaddon,pac

   Example output

   NAME                                                             VERSION   READY   REASON
   tektonpipeline.operator.tekton.dev/pipeline                      v0.47.0   True
   
   NAME                                                             VERSION   READY   REASON
   tektontrigger.operator.tekton.dev/trigger                        v0.23.1   True
   
   NAME                                                             VERSION   READY   REASON
   tektonchain.operator.tekton.dev/chain                            v0.16.0   True
   
   NAME                                                             VERSION   READY   REASON
   tektonaddon.operator.tekton.dev/addon                            1.11.0     True
   
   NAME                                                             VERSION   READY   REASON
   openshiftpipelinesascode.operator.tekton.dev/pipelines-as-code   v0.19.0   True

Procedure

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

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

   spec.channel

   Name of the channel that you want to subscribe. The pipelines-<version> channel is the default channel. For example, the default channel for Red Hat OpenShift Pipelines Operator version 1.7 is pipelines-1.7. The latest channel enables installation of the most recent stable version of the Red Hat OpenShift Pipelines Operator.

   spec.name

   Name of the Operator to subscribe to.

   spec.source

   Name of the CatalogSource object that provides the Operator.

   spec.sourceNamespace

   Namespace of the CatalogSource object. Use openshift-marketplace for the default OperatorHub catalog sources.

2. Create the Subscription object by running the following command:

   $ oc apply -f sub.yaml

   The subscription installs the Red Hat OpenShift Pipelines Operator into the openshift-operators namespace. The Operator automatically installs OpenShift Pipelines into the default openshift-pipelines target namespace.

Procedure

1. In the Administrator perspective of the web console, navigate to Administration → CustomResourceDefinitions.
2. Type TektonHub in the Filter by name field to search for the TektonHub Custom Resource Definition (CRD).
3. Click the name of the TektonHub CRD to display the details page for the CRD.
4. Click the Instances tab.
5. If an instance is displayed, click the Options menu for the displayed instance.
6. Select Delete TektonHub.
7. Click Delete to confirm the deletion of the CR.
8. Repeat these steps, searching for TektonResult and then TektonConfig in the Filter by name box. If any instances are found for these custom resource definitions (CRDs), delete these instances.

Procedure

1. From the Operators → OperatorHub page, use the Filter by keyword box to search for the Red Hat OpenShift Pipelines Operator.
2. Click the Red Hat OpenShift Pipelines Operator tile. The Operator tile indicates that the Operator is installed.
3. In the Red Hat OpenShift Pipelines Operator description page, click Uninstall.
4. In the Uninstall Operator? window, select Delete all operand instances for this operator, and then click Uninstall.

Procedure

1. In the Administrator perspective of the web console, navigate to Administration → CustomResourceDefinitions.
2. Type operator.tekton.dev in the Filter by name box to search for the CRDs in the operator.tekton.dev group.

3. To delete each of the displayed CRDs, complete the following steps:

   1. Click the Options menu .
   2. Select Delete CustomResourceDefinition.
   3. Click Delete to confirm the deletion of the CRD.

Procedure

1. In the Administrator perspective of the web console, navigate to Administration → CustomResourceDefinitions.
2. Use the Search by name box to search for the tektonconfigs.operator.tekton.dev custom resource definition (CRD). Click TektonConfig to see the CRD details page.
3. Click the Instances tab.
4. Click the config instance to see the TektonConfig CR details.
5. Click the YAML tab.

6. Edit the TektonConfig YAML file based on your requirements.

   Example TektonConfig CR

   apiVersion: operator.tekton.dev/v1alpha1
   kind: TektonConfig
   metadata:
     name: config
   spec:
     pipeline:
       running-in-environment-with-injected-sidecars: true
       metrics.taskrun.duration-type: histogram
       metrics.pipelinerun.duration-type: histogram
       await-sidecar-readiness: true
       params:
         - name: enableMetrics
           value: 'true'
       default-service-account: pipeline
       require-git-ssh-secret-known-hosts: false
       enable-tekton-oci-bundles: false
       metrics.taskrun.level: task
       metrics.pipelinerun.level: pipeline
       enable-api-fields: stable
       enable-provenance-in-status: false
       enable-custom-tasks: true
       disable-creds-init: false
       disable-affinity-assistant: true

Procedure

1. Edit the TektonConfig CR by running the following command:

   $ oc edit TektonConfig config

2. In the TektonConfig CR, set the resolverTasks and pipelineTemplates parameter value in .addon.params spec to false:

   Example of disabling resolver task and pipeline template resources

   apiVersion: operator.tekton.dev/v1alpha1
   kind: TektonConfig
   metadata:
     name: config
   spec:
   # ...
     addon:
       params:
         - name: resolverTasks
           value: 'false'
         - name: pipelineTemplates
           value: 'false'
   # ...

   Important

   You can set the value of the pipelinesTemplates parameter to true only when the value of the resolverTasks parameter is true.

Procedure

1. Edit the TektonConfig CR by running the following command:

   $ oc edit TektonConfig config

2. In the TektonConfig CR, set the createRbacResource param value to false:

   apiVersion: operator.tekton.dev/v1alpha1
   kind: TektonConfig
   metadata:
     name: config
   spec:
     params:
     - name: createRbacResource
       value: "false"
   # ...

Procedure

1. In your TektonConfig CR, disable the job-based pruner by setting spec.pruner.disabled field to true and enable the event-driven pruner by setting the spec.tektonpruner.disabled field to false.

   For example:

   apiVersion: operator.tekton.dev/v1alpha1
   kind: TektonConfig
   metadata:
    name: config
   spec:
     # ...
     pruner:
       disabled: true
     # ...
     tektonpruner:
       disabled: false
       options: {}
     # ...

   After you apply the updated CR, the Operator deploys the tekton-pruner-controller pod in the openshift-pipelines namespace.

2. Ensure that the following config maps are present in the openshift-pipelines namespace:

   Expand

   Config map	Purpose
   tekton-pruner-default-spec	Define default pruning behavior
   pruner-info	Store internal runtime data used by the controller
   config-logging-tekton-pruner	Configure logging settings for the pruner
   config-observability-tekton-pruner	Enable observability features such as metrics and tracing

   Show more

Verification

1. To verify that the tekton-pruner-controller pod is running, run the following command:

   $ oc get pods -n openshift-pipelines

2. Verify that the output includes a tekton-pruner-controller and tekton-pruner-webhook pods in the Running state.

   Example output:

   $ tekton-pruner-controller-<id>       Running
     tekton-pruner-webhook-<id>          Running

Procedure

1. View the list of webhooks that the OpenShift Pipelines controllers created. There are two types of webhooks: mutating webhooks and validating webhooks.

   1. To view the list of mutating webhooks, enter the following command:

      $ oc get MutatingWebhookConfiguration

      Example output

      NAME                             WEBHOOKS   AGE
      annotation.operator.tekton.dev   1          4m20s
      proxy.operator.tekton.dev        1          4m20s
      webhook.operator.tekton.dev      1          4m22s
      webhook.pipeline.tekton.dev      1          4m20s
      webhook.triggers.tekton.dev      1          3m50s

   2. To view the list of validating webhooks, enter the following command:

      $ oc get ValidatingWebhookConfiguration

      Example output

      NAME                                                 WEBHOOKS   AGE
      config.webhook.operator.tekton.dev                   1          4m24s
      config.webhook.pipeline.tekton.dev                   1          4m22s
      config.webhook.triggers.tekton.dev                   1          3m52s
      namespace.operator.tekton.dev                        1          4m22s
      validation.pipelinesascode.tekton.dev                1          2m49s
      validation.webhook.operator.tekton.dev               1          4m24s
      validation.webhook.pipeline.tekton.dev               1          4m22s
      validation.webhook.triggers.tekton.dev               1          3m52s

2. In the TektonConfig custom resource (CR), add configuration for mutating and validating webhooks under the section for each of the controllers as necessary, as shown in the following examples. Use the validation.webhook.pipeline.tekton.dev spec for the validating webhooks and the webhook.pipeline.tekton.dev spec for the mutating webhooks.

   Important
   • You cannot set configuration for operator webhooks.
   • All settings are optional. For example, you can set the timeoutSeconds parameter and omit the failurePolicy and sideEffects parameters.

   Example settings for the Pipelines controller

   apiVersion: operator.tekton.dev/v1
   kind: TektonConfig
   metadata:
     name: config
   spec:
     pipeline:
       options:
         webhookConfigurationOptions:
           validation.webhook.pipeline.tekton.dev:
             failurePolicy: Fail
             timeoutSeconds: 20
             sideEffects: None
           webhook.pipeline.tekton.dev:
             failurePolicy: Fail
             timeoutSeconds: 20
             sideEffects: None

   Example settings for the Triggers controller

   apiVersion: operator.tekton.dev/v1
   kind: TektonConfig
   metadata:
     name: config
   spec:
     triggers:
       options:
         webhookConfigurationOptions:
           validation.webhook.triggers.tekton.dev:
             failurePolicy: Fail
             timeoutSeconds: 20
             sideEffects: None
           webhook.triggers.tekton.dev:
             failurePolicy: Fail
             timeoutSeconds: 20
             sideEffects: None

   Example settings for the Pipelines as Code controller

   apiVersion: operator.tekton.dev/v1
   kind: TektonConfig
   metadata:
     name: config
   spec:
     pipelinesAsCode:
       options:
         webhookConfigurationOptions:
           validation.pipelinesascode.tekton.dev:
             failurePolicy: Fail
             timeoutSeconds: 20
             sideEffects: None
           pipelines.triggers.tekton.dev:
             failurePolicy: Fail
             timeoutSeconds: 20
             sideEffects: None

   Example settings for the Tekton Hub controller

   apiVersion: operator.tekton.dev/v1
   kind: TektonConfig
   metadata:
     name: config
   spec:
     hub:
       options:
         webhookConfigurationOptions:
           validation.webhook.hub.tekton.dev:
             failurePolicy: Fail
             timeoutSeconds: 20
             sideEffects: None
           webhook.hub.tekton.dev:
             failurePolicy: Fail
             timeoutSeconds: 20
             sideEffects: None