Red Hat OpenShift Pipelines release notes

With this update, when incorporating a step from another custom resource (CR) using a stepRef: section, you can use parameters in the same way that you use parameters in taskRef: and pipelineRef: sections.

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: test-task
spec:
  steps:
  - name: fetch-repository
    stepRef:
      resolver: git
      params:
      - name: url
        value: https://github.com/tektoncd/catalog.git
      - name: revision
        value: main
      - name: pathInRepo
        value: stepaction/git-clone/0.1/git-clone
    params:
    - name: url
      value: $(params.repo-url)
    - name: revision
      value: $(params.tag-name)
    - name: output-path
      value: $(workspaces.output.path)

Before this update, when using a resolver to incorporate a task or pipeline from a remote source, if one of the parameters expected an array you had to specify the type of the parameter explicitly. With this update, when using a resolver to incorporate a task or pipeline from a remote source, you do not have to set the type of any parameters.

With this update, when specifying the use of a workspace in a pipeline run or task run, you can use parameters and other variables in the specification in the secret, configMap, and projected.sources sections.

apiVersion: tekton.dev/v1
kind: Task
metadata:
  generateName: something-
spec:
  params:
  - name: myWorkspaceSecret
  steps:
  - image: registry.redhat.io/ubi/ubi8-minimal:latest
    script: |
      echo “Hello World”
  workspaces:
  - name: myworkspace
    secret:
      secretName: $(params.myWorkspaceSecret)

By default, when OpenShift Pipelines fails to pull the container image that is required for the execution of a task, the task fails. With this release, you can configure an image pull backoff timeout. If you configure this timeout, when OpenShift Pipelines fails to pull the container image that is required for the execution of a task, it continues to attempt to pull the image for the specified time period. The task fails if OpenShift Pipelines is unable to pull the image within the specified period.

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    options:
      configMaps:
          config-defaults:
              data:
                   default-imagepullbackoff-timeout: "5m"

With this release, the YAML manifest of a completed pipeline run or task run includes a displayName field in the childReferences section. This field contains the display name of the pipeline run or task run, which can differ from the full name of the pipeline run or task run.

With this update, the YAML manifest of every step in a completed TaskRun CR includes a new terminationReason field. This field contains the reason the step execution ended. OpenShift Pipelines uses the following values for the terminationReason field:

With this update, you can use the pipeline.disable-inline-spec spec in the TektonConfig CR to disable specifying pipelines and tasks inside PipelineRun CRs, specifying tasks inside Pipeline CRs, or specifying tasks inside TaskRun CRs. If you use this option, you must refer to pipelines by using the pipelineRef: specification and refer to tasks by using the taskRef: specification.

With this update, some metrics for Prometheus monitoring of OpenShift Pipelines were renamed to ensure compliance with the Prometheus naming convention. Gauge and Counter metric names no longer end with count.

With this update, several tasks are added to the openshift-pipelines namespace in the resolverTasks add-on. You can incorporate these tasks in your pipelines using the cluster resolver. Most of these tasks were previously available as cluster tasks (ClusterTask resources). You can access the following tasks by using the cluster resolver:

With this update, you can set the pruner.startingDeadlineSeconds spec in the TektonConfig CR. If the pruner job that removes old resources associated with pipeline runs and task runs is not started at the scheduled time for any reason, this setting configures the maximum time, in seconds, in which the job can still be started. If the job is not started within the specified time, OpenShift Pipelines considers this job failed and starts the pruner at the next scheduled time.

With this update, you can use the targetNamespaceMetadata spec in the TektonConfig CR to set labels and annotations for the openshift-pipelines namespace in which the Operator installs OpenShift Pipelines.

With this update, error messages for the OpenShift Pipelines Operator include additional context information such as namespace.

With this update, you can use the TriggerTemplate CR to specify templates for any types of resources. When the trigger is invoked, OpenShift Pipelines creates the resources that you define in the TriggerTemplate CR for the trigger. In the following example, a ConfigMap resource is created when the trigger is invoked:

apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerTemplate
metadata:
  name: create-configmap-template
spec:
  params:
    - name: action
  resourcetemplates:
    - apiVersion: v1
      kind: ConfigMap
      metadata:
        generateName: sample-
      data:
        field: "Action is : $(tt.params.action)"

With this update, you can define the ServiceType in an eventListener CR as NodePort and define the port number for the event listener, as shown in the following example:

apiVersion: triggers.tekton.dev/v1beta1
kind: eventListener
metadata:
  name: simple-eventlistener
spec:
  serviceAccountName:  simple-tekton-robot
  triggers:
    - name: simple-trigger
      bindings:
      - ref: simple-binding
      template:
        ref: simple-template
  resources:
    kubernetesResource:
      serviceType: NodePort
      servicePort: 38080

With this update, if you use a serviceType value of LoadBalancer in an eventListener CR, you can optionally specify a load balancer class in the serviceLoadBalancerClass field. If your cluster provides multiple load balancer controllers, you can use the load balancer class to select one of these controllers. For more information about setting a load balancer class, see the Kubernetes documentation.

apiVersion: triggers.tekton.dev/v1beta1
kind: eventListener
metadata:
  name: listener-loadbalancerclass
spec:
  serviceAccountName: tekton-triggers-example-sa
  triggers:
    - name: example-trig
      bindings:
        - ref: pipeline-binding
        - ref: message-binding
      template:
        ref: pipeline-template
  resources:
    kubernetesResource:
      serviceType: LoadBalancer
      serviceLoadBalancerClass: private

You must set the following parameters in the ApprovalTask specification:

The manual approval gate supports approval from multiple users:

Users can provide approval using the opc approvaltask CLI and the OpenShift web console. Approval in the OpenShift web console requires installation of the OpenShift Pipelines web console plugin. This plugin requires OpenShift Container Platform version 4.15 or later.

Users can add messages while approving or rejecting the approvalTask.

You can add a timeout setting to the approvalTask specification. If the required number of approvals is not provided during this time period, the pipeline run fails.

With this update, the tkn command line utility supports the -e or --exit-with-pipelinerun-error option for the pipeline showlog command. With this option, the command line utility returns an error code of 0 if the pipeline run completed successfully, 1 if the pipeline run ended with an error, and 2 if the status of the pipeline run is unknown.

With this update, the tkn command line utility supports the --label option for the bundle push command. With this option, you can provide the value of a label in the <label-name>=<value> format; the utility adds the label to the OCI image that it creates. You can use this option several times to provide several labels for the same image.

With this update, when using Pipelines as Code, you can set a pipelinesascode.tekton.dev/on-comment annotation on a pipeline run to start the pipeline run when a developer adds a matching comment to a pull request. This setting is supported only for pull requests and only for GitHub and GitLab repository providers.

With this update, when using Pipelines as Code, you can enter the /test <pipeline_run_name> comment on a pull request to start any Pipelines as Code pipeline run on the repository, whether or not it was triggered by an event for this pipeline run. This feature is Technological preview only.

With this update, when providing a /test or /retest command for Pipelines as Code in a Git request comment, you can now set any standard or custom parameters for the pipeline run.

/test pipelinerun1 revision=main param1="value1" param2="value \"value2\" with quotes"

/test checker target_branch=backport-branch

With this update, when using Pipelines as Code, you can create a global Repository CR with the name pipelines-as-code in the namespace in which OpenShift Pipelines is installed, normally openshift-pipelines. In this CR, you can set the configuration options that apply to all Repository CRs. You can override any of these default options by setting different values in the Repository CR for a particular repository.

With this update, Pipelines as Code processes both the OWNeRS file and the OWNeRS_ALIASeS file when determining which users can trigger pipeline runs. However, if the OWNeRS file includes a filters section, Pipelines as Code matches approvers and reviewers only against the .* filter.

With this update, when Pipelines as Code generates a random secret name for storing the GitHub temporary token, it uses two additional random characters. This change decreases the probability of a collision in secret names.

With this update, when a pipeline run defined by using Pipelines as Code causes a YAML validation error, OpenShift Pipelines reports the error and the pipeline run name in the event log of the user namespace where the pipeline run executes, as well as in the OpenShift Pipelines controller log. The error report is also displayed in the Git repository provider, for example, in the GitHub CheckRun user interface. With this change, a user who does not have access to the controller namespace can access the error messages.

Tekton Results uses an UpdateLog operation to store logging information in the database. With this update, you can use the TektonResult CR to specify a timeout value for this operation. If the operation does not complete within the specified time period, Tekton Results ends the operation.

apiVersion: operator.tekton.dev/v1
kind: TektonResult
metadata:
  name: result
spec:
     options:
        deployments:
           tekton-results-watcher:
              spec:
                  template:
                     spec:
                        containers:
                        - name: watcher
                          args:
                          - "--updateLogTimeout=60s"

With this update, when configuring Tekton Results, you can optionally specify the following database configuration settings in the options.configMaps.tekton-results-api-config.data.config section of the TektonResult CR:

With this update, you can use the Tekton Results API to retrieve the Go profiling data for Tekton Results.

Before this update, Tekton Results checked the user authentication when displaying every fragment of log data. With this update, Tekton Results checks the user authentication only once per log data request. This change improves the response time for the Tekton Results log API, which is used for displaying logs using the command line utility.

Before this update, in the TektonConfig CR, the chain.artifacts.pipelinerun.enable-deep-inspection spec supported only the bool value type. With this update, the chain.artifacts.pipelinerun.enable-deep-inspection spec supports both the bool and string value types; if using the string value type, the valid values for this spec are "true" and "false".

Before this update, when you used the git-clone task, which is available from the openshift-pipelines namespace, this task did not return the COMMIT result. With this update, the task returns the correct value in the COMMIT result.

Before this update, when you used a resolver to include a StepAction resource in a pipeline or task, the pipeline or task failed and an extra params passed by Step to StepAction error message was logged. With this update, the pipeline or task completes correctly.

Before this update, when you enabled the OpenShift Pipelines plugin, viewed the details page for a pipeline in the web console, and selected edit Pipeline from the menu, the console displayed the YAML specification of the pipeline. With this update, the console displays the Pipeline Builder page.

Before this update, in OpenShift Pipelines version 1.15.0, when you added a comment on a pull request, Pipelines as Code set an event type depending on the comment content, for example, retest-comment or on-comment. With this update, the event type after a pull request comment is always pull_request, similar to OpenShift Pipelines version 1.14 and earlier.

Before this update, when you passed a parameter value to a pipeline or task and the value included more than one variable with both full and short reference formats, for example, $(tasks.task-name.results.variable1) + $(variable2), OpenShift Pipelines did not interpret the value correctly. The pipeline run or task run could stop execution and the Pipelines controller could crash. With this update, OpenShift Pipelines interprets the value correctly and the pipeline run or task run completes.

Before this update, in the web console, sorting of pipeline runs and task runs by creation time did not work. Sorting of pipelines by last run time also did not work. With this update, the sorting works correctly.

Before this update, in the web console, if you enabled the OpenShift Pipelines console plugin, when starting a pipeline you could not select the storage class for the volume claim template, because the StorageClass list was not present in the VolumeClaimTemplate options. With this update, you can select the storage class for the volume claim template.

Before this update, if you used Pipelines as Code, the list of pipeline runs did not display correctly in the Repository details page of the web console. With this update, the list of pipeline runs displays correctly.

With this update, you can use a parameter of a task or pipeline or a result of a previous task to specify the name of a resource to bind to a workspace, for example, name: $(params.name)-configmap.

With this update, OpenShift Pipelines supports using your existing entitlements for Red Hat enterprise Linux in build processes within your pipelines. The built-in buildah cluster task can now use these entitlements.

With this update, if a pipeline run or task run uses the pipeline service account, you can use CSI volume types in the pipeline or task.

With this update, you can use a StepAction custom resource (CR) to define a reusable scripted action that you can invoke from any number of tasks. To use this feature, you must set the pipeline.options.configMaps.feature-flags.data.enable-step-actions spec in the TektonConfig CR to true.

With this update, object parameters and array results are enabled by default. You do not need to set any flags to use them.

With this update, you can use the HTTP resolver to fetch a pipeline or task from an HTTP URL, as shown in the following examples:

apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: remote-task-reference
spec:
  taskRef:
    resolver: http
    params:
    - name: url
      value: https://raw.githubusercontent.com/tektoncd-catalog/git-clone/main/task/git-clone/git-clone.yaml

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: http-demo
spec:
  pipelineRef:
    resolver: http
    params:
    - name: url
      value: https://raw.githubusercontent.com/tektoncd/catalog/main/pipeline/build-push-gke-deploy/0.1/build-push-gke-deploy.yaml

With this update, you can use an enum declaration to limit the values that you can supply for a parameter of a pipeline or task, as shown in the following example. To use this feature, you must set the pipeline.options.configMaps.feature-flags.data.enable-param-enum spec in the TektonConfig CR to true.

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: pipeline-param-enum
spec:
  params:
  - name: message
    enum: ["v1", "v2"]
    default: "v1"
# ...

With this update, when using the Git resolver with the authenticated source control management (SCM) API, you can override the default token, SCM type, and server URL that you configured. See the following example:

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: git-api-demo-tr
spec:
  taskRef:
    resolver: git
    params:
    - name: org
      value: tektoncd
    - name: repo
      value: catalog
    - name: revision
      value: main
    - name: pathInRepo
      value: task/git-clone/0.6/git-clone.yaml
    # create the my-secret-token secret in the namespace where the
    # pipelinerun is created. The secret must  contain a GitHub personal access
    # token in the token key of the secret.
    - name: token
      value: my-secret-token
    - name: tokenKey
      value: token
    - name: scmType
      value: github
    - name: serverURL
      value: https://ghe.mycompany.com

With this update, you can define default resource requirements for containers and init-containers in pods that OpenShift Pipelines creates when executing task runs. Use the pipeline.options.configMaps.config-defaults.default-container-resource-requirements spec in the TektonConfig CR to set these requirements. You can set the default values for all containers and also for particular containers by name or by prefix, such as sidecar-*.

With this update, OpenShift Pipelines supports horizontal pod autoscaling for the Operator proxy webhook. If the pod that runs the Operator proxy webhook reaches 85% CPU utilization, the autoscaler creates another replica of the pod. If you want to use more than one replica for the Operator proxy webhook at startup, you must configure this number in the options.horizontalPodAutoscalers spec of the TektonConfig CR.

With this update, the internal leader election for several components of OpenShift Pipelines was improved. The Operator controller, Operator webhook, proxy webhook, Pipelines as Code watcher, Pipelines as Code webhook, and the Tekton Chains controller now use separate leader election ConfigMaps. The leader election affects which replica of a component processes a request.

Before this update, when you scaled up the number of replicas of the OpenShift Pipelines controller, manual intervention was required to enable the use of the new replicas; namely, you needed to delete leases in the leader election. With this update, when you scale up the number of replicas of the OpenShift Pipelines controller, the leader election includes the new replicas automatically, so the new replicas can process information.

With this update, you can optionally set the following flags in the spec.pipeline spec of the TektonConfig CR:

With this update, when specifying CeL expressions for the Triggers interceptor, you can use the first and last functions to access values in a JSON array.

With this update, when specifying CeL expressions for the Triggers interceptor, you can use the translate function that facilitates the utilization of regular expressions to replace characters with specified strings, as in the following example:

".translate("[^a-z0-9]+", "ABC")

This is $an Invalid5String

ABChisABCisABCanABCnvalid5ABCtring

With this update, you can enable the web console plugin for OpenShift Pipelines. If you enable the plugin, you can view pipeline and task execution statistics in the Pipelines overview page and in the page of a pipeline. You must install Tekton Results to view this information.

With this update, if you are using OpenShift Container Platform 4.15 and you enabled the console plugin, you can view archive information about past pipeline runs and task runs. Tekton Results provides this information.

With this update, the PipelineRun details page, accessible from both the Developer or Administrator perspective of the web console, introduces a Vulnerabilities row. This new row offers a visual representation of identified vulnerabilities, categorized by severity (critical, high, medium, and low). To enable this feature, update your tasks and associated pipelines to the specified format. Additionally, once enabled, you can also access the information about identified vulnerabilities through the Vulnerabilities column in the pipeline run list view page.

With this update, the PipelineRun details page, accessible from both the Developer or Administrator perspective of the web console, provides an option to download or view Software Bill of Materials (SBOMs) for enhanced transparency and control. To enable this feature, update your tasks and associated pipelines to the specified format.

With this update, the tkn version command displays the version of the Tekton Hub component if this component is installed.

With this update, you can use the tkn customrun list command to list custom runs.

With this update, when using the tkn task start command, you can specify a URL for an OCI image in the -i or --image argument. The command pulls the image and runs the specified task from this image.

With this update, the opc version command displays the version of the Tekton Results CLI component, which is a part of the opc utility.

With this update, when using Pipelines as Code, you can specify the pipelinesascode.tekton.dev/pipeline annotation on a pipeline run to fetch the pipeline from a Tekton Hub instance. The value of this annotation must refer to a single pipeline on Tekton Hub.