Red Hat OpenShift Pipelines release notes

With this update, you can configure the resync period for the pipelines controller. For every resync period, the controller reconciles all pipeline runs and task runs, regardless of events. The default resync period is 10 hours. If you have a large number of pipeline runs and task runs, a full reconciliation every 10 hours might consume too many resources. In this case, you can configure a longer resync period.

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    options:
      deployments:
        tekton-pipelines-controller:
          spec:
            template:
              spec:
                containers:
                - name: tekton-pipelines-controller
                  args:
                    - "-resync-period=24h"
# ...

With this update, when defining a pipeline, you can set the onError parameter for a task to continue. If you make this setting and the task fails when the pipeline is executed, the pipeline logs the error and continues to the next task. By default, a pipeline fails if a task in it fails.

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: example-onerror-pipeline
spec:
  tasks:
  - name: task-that-fails
    onError: continue
    taskSpec:
      steps:
      - image: alpine
        name: exit-with-1
        script: |
          exit 1
  - name: next-task
# ...

With this update, if a task fails, a finally task can access the reason parameter in addition to the status parameter to distinguish if the failure was allowed or not. You can access the reason parameter through $(tasks.<task_name>.reason). If the failure is allowed, the reason is set to FailureIgnored. If the failure is not allowed, the reason is set to Failed. This additional information can be used to identify that the checks failed, but the failure can be ignored.

With this update, larger results are supported through sidecar logs as an alternative to the default configuration, which limits results to the size of 4 KB per step and 12 KB per task run. To enable larger results using sidecar logs, set the pipeline.options.configMaps.feature-flags.data.results-from spec to sidecar-logs in the TektonConfig CR.

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    options:
      configMaps:
        feature-flags:
          data:
            results-from: "sidecar-logs"
# ...

Before this update, parameter propagation was allowed in PipelineRun and TaskRun resources, but not in the Pipeline resource. With this update, you can propagate params in the Pipeline resource down to the inlined pipeline tasks and its inlined steps. Wherever a resource, such as PipelineTask or StepAction, is referenced, you must pass the parameters explicitly.

apiVersion: tekton.dev/v1 # or tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: pipeline-propagated-params
spec:
  params:
    - name: HELLO
      default: "Hello World!"
    - name: BYE
      default: "Bye World!"
  tasks:
    - name: echo-hello
      taskSpec:
        steps:
          - name: echo
            image: ubuntu
            script: |
              #!/usr/bin/env bash
              echo "$(params.HELLO)"
    - name: echo-bye
      taskSpec:
        steps:
          - name: echo-action
            ref:
              name: step-action-echo
            params:
              - name: msg
                value: "$(params.BYE)"
# ...

With this update, you can use the task run or pipeline run definition to configure the compute resources for steps and sidecars in a task.

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: side-step
spec:
  steps:
    - name: test
      image: docker.io//alpine:latest
  sidecars:
    - name: side
      image: docker.io/linuxcontainers/alpine:latest
# ...

apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: test-sidestep
spec:
  taskRef:
    name: side-step
  stepSpecs:
    - name: test
      computeResources:
        requests:
          memory: 1Gi
  sidecarSpecs:
    - name: side
      computeResources:
        requests:
          cpu: 100m
        limits:
          cpu: 500m
# ...

With this update, OpenShift Pipelines includes the git-clone StepAction definition for a step that clones a Git repository. Use the HTTP resolver to reference this definition. The URL for the definition is https://raw.githubusercontent.com/openshift-pipelines/tektoncd-catalog/p/stepactions/stepaction-git-clone/0.4.1/stepaction-git-clone.yaml. The StepAction definition is also installed in the openshift-pipelines namespace. However, the cluster resolver does not support StepAction definitions.

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: clone-repo-anon
spec:
  params:
  - name: url
    description: The URL of the Git repository to clone
  workspaces:
  - name: output
    description: The git repo will be cloned onto the volume backing this Workspace.
  steps:
  - name: clone-repo-anon-step
    ref:
      resolver: http
      params:
      - name: url
        value: https://raw.githubusercontent.com/openshift-pipelines/tektoncd-catalog/p/stepactions/stepaction-git-clone/0.4.1/stepaction-git-clone.yaml
    params:
    - name: URL
      value: $(params.url)
    - name: OUTPUT_PATH
      value: $(workspaces.output.path)
# ...

With this update, the openshift-pipelines namespace includes versioned tasks alongside standard tasks. For example, there is a buildah standard task and a buildah-1-16-0 versioned task. While the standard task might be updated in subsequent releases, the versioned task remains exactly the same as it was in a specified version, except for the correction of errors.

With this update, you can configure the FailurePolicy, TimeoutSeconds, and SideEffects options for webhooks for several components of OpenShift Pipelines by using the TektonConfig CR. The following example shows the configuration for the pipeline component. You can use similar configuration for webhooks in the triggers, pipelinesAsCode, and hub components.

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

With this update, the readOnlyRootFilesystem parameter for the triggers controller, webhook, Core Interceptor, and event listener is set to true by default to improve security and avoid being flagged by the security scanner.

With this update, you can configure OpenShift Pipelines triggers to run event listeners as a non-root user within the container. To set this option, set the parameters in the TektonConfig CR as shown in the following example:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  trigger:
    options:
      disabled: false
      configMaps:
        config-defaults-triggers:
          data:
            default-run-as-non-root: "true"
            default-run-as-user: "65532"
            default-run-as-group: "65532"
            default-fs-group: "65532"
# ...

With this update, in triggers, the EventListener pod template now includes securityContext settings. Under these settings, you can configure seccompProfile, runAsUser, runAsGroup, and fsGroup parameters when the el-security-context flag is set to true.

Before this release, when using the web console, you could not see the timestamp for the logs that OpenShift Pipelines created. With this update, the web console includes timestamps for all OpenShift Pipelines logs.

With this update, the pipeline run and task run list pages in the web console now have a filter for the data source, such as k8s and TektonResults API.

Before this update, when using the web console in the Developer perspective, you could not specify the timeout for pipeline runs. With this update, you can set a timeout while starting the pipeline run in the Developer perspective of the web console.

Before this update, the Overview pipeline dashboard only appeared when Tekton Results was enabled. All the statistics came from only the Results API. With this update, the Overview pipeline dashboard is available regardless of whether Tekton Results is enabled or not. When Tekton Results is disabled, you can use the dashboard to see the statistics for objects in the cluster.

With this update, the sample pipelines displayed in the web console use the v1 version of the OpenShift Pipelines API.

With this update, you can use the tkn customrun delete <custom_run_names> command to delete one or more custom runs.

With this update, when you run a tkn <resource> list command with the -o YAML flag, the listed resources are now separated with --- separators to enhance readability of the output.

With this update, if you create two PipelineRun definitions with the same name, Pipelines as Code logs an error and does not run either of these pipeline runs.

With this update, the Pipelines as Code pipelines_as_code_pipelinerun_count metric allows filtering of the PipelineRun count by repository or namespace.

With this update, the readOnlyRootFilesystem security context for the Pipelines as Code controller, webhook, and watcher is set to true by default to increase security and avoid being flagged by the security scanner.

With this update, when using docdb storage in Tekton Chains, you can configure the MONGO_SERVER_URL value directly in the TektonConfig CR as the storage.docdb.mongo-server-url setting. Alternatively, you can provide this value using a secret and set the storage.docdb.mongo-server-url-dir setting to the directory where the MONGO_SERVER_URL file is located.

$ oc create secret generic mongo-url -n tekton-chains \ #
  --from-file=MONGO_SERVER_URL=/home/user/MONGO_SERVER_URL

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  chain:
    disabled: false
    storage.docdb.mongo-server-url-dir: /tmp/mongo-url
    options:
      deployments:
        tekton-chains-controller:
          spec:
            template:
              spec:
                containers:
                - name: tekton-chains-controller
                  volumeMounts:
                  - mountPath: /tmp/mongo-url
                    name: mongo-url
                volumes:
                -  name: mongo-url
                   secret:
                    secretName: mongo-url
# ...

With this update, when using KMS signing in Tekton Chains, instead of providing the KMS authentication token value directly in the configuration, you can provide the token value as a secret by using the signers.kms.auth.token-path setting.

$ oc create secret generic <secret_name> -n tekton-chains \
  --from-file=KMS_AUTH_TOKEN=/home/user/KMS_AUTH_TOKEN (1)

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  chain:
    disabled: false
    signers.kms.auth.token-path: /etc/kms-secrets/KMS_AUTH_TOKEN
    options:
      deployments:
        tekton-chains-controller:
          spec:
            template:
              spec:
                containers:
                - name: tekton-chains-controller
                  volumeMounts:
                  - mountPath: /etc/kms-secrets
                    name: kms-secrets
                volumes:
                -  name: kms-secrets
                   secret:
                    secretName: kms-secrets
# ...

With this update, you can configure a list of namespaces as an argument to the Tekton Chains controller. If you provide this list, Tekton Chains watches pipeline runs and task runs only in the specified namespaces. If you do not provide this list, Tekton Chains watches pipeline runs and task runs in all namespaces.

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  chain:
    disabled: false
    options:
      deployments:
        tekton-chains-controller:
          spec:
            template:
              spec:
                containers:
                - args:
                  - --namespace=dev, test
                  name: tekton-chains-controller
# ...

Before this update, Tekton Results used the v1beta1 API format to store TaskRun and PipelineRun object records. With this update, Tekton Results uses the v1 API format to store TaskRun and PipelineRun object records.

With this update, Tekton Results can automatically convert existing records to the v1 API format. To enable such conversion, set parameters in the TektonResult CR as shown in the following example:

  apiVersion: operator.tekton.dev/v1alpha1
kind: TektonResult
metadata:
  name: result
spec:
  options:
    deployments:
      tekton-results-api:
        spec:
          template:
            spec:
              containers:
                - name: api
                  env:
                    - name: CONVERTER_ENABLE
                      value: "true"
                    - name: CONVERTER_DB_LIMIT
                      value: "256" (1)
# ...

With this update, Tekton Results now supports fetching forwarded logs from third party logging APIs. You can enable the logging API through the TektonResult CR by setting the logs_api to true and logs_type to Loki.

With this update, you can configure automatic pruning of the Tekton Results database. You can specify the number of days for which records must be stored. You can also specify the schedule for running the pruner job that removes older records. To set these parameters, edit the TektonResult CR, as shown in the following example:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonResult
metadata:
  name: result
spec:
  options:
    configMaps:
      config-results-retention-policy:
        data:
          runAt: "3 5 * * 0" (1)
          maxRetention: "30" (2)
# ...

With this update, you can configure Tekton Results to store event logs for pipelines and tasks. To enable storage of event logs, edit the TektonResult CR, as shown in the following example:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonResult
metadata:
  name: result
spec:
  options:
     deployments:
        tekton-results-watcher:
          spec:
            template:
              spec:
                containers:
                  - name: watcher
                    args:
                      - "--store_event=true"
# ...

With this update, you can configure Tekton Results to use the OpenShift Container Platform Cluster Log Forwarder to store all log data in a LokiStack instance, instead of placing it directly on a storage volume. This option enables scaling to a higher rate of pipeline runs and task runs.

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: collector
  namespace: openshift-logging
spec:
  inputs:
  - application:
      selector:
        matchLabels:
          app.kubernetes.io/managed-by: tekton-pipelines
    name: only-tekton
    type: application
  managementState: Managed
  outputs:
  - lokiStack:
      labelKeys:
        application:
          ignoreGlobal: true
          labelKeys:
          - log_type
          - kubernetes.namespace_name
          - openshift_cluster_id
      authentication:
        token:
          from: serviceAccount
      target:
        name: logging-loki
        namespace: openshift-logging
    name: default-lokistack
    tls:
      ca:
        configMapName: openshift-service-ca.crt
        key: service-ca.crt
    type: lokiStack
  pipelines:
  - inputRefs:
    - only-tekton
    name: default-logstore
    outputRefs:
    - default-lokistack
  serviceAccount:
    name: collector
# ...

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  inputs:
  - name: only-tekton
    application:
      selector:
        matchLabels:
          app.kubernetes.io/managed-by: tekton-pipelines
  pipelines:
    - name: enable-default-log-store
      inputRefs: [ only-tekton ]
      outputRefs: [ default ]
# ...

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonResult
metadata:
  name: result
spec:
  targetNamespace: tekton-pipelines
# ...
  loki_stack_name: logging-loki
  loki_stack_namespace: openshift-logging
# ...