Chapter 1. Red Hat OpenShift Pipelines release notes

Pipelines

hostUsers support in podTemplate for user namespace isolation

With this update, OpenShift Pipelines supports the hostUsers setting in the podTemplate field. You can configure the Kubernetes-native user namespace isolation on OpenShift Container Platform 4.20 and later without using legacy CRI-O annotations. Setting hostUsers lets you explicitly control host user namespace sharing for both TaskRun and PipelineRun workloads.

SRVKP-9726

The HTTP resolver supports content verification with a hash parameter

With this update, the HTTP resolver includes an optional hash parameter that accepts SHA-256 or SHA-512 hashes of the expected content. When you provide a hash, the resolver verifies content integrity after fetching by comparing the hash of the received content against the expected value. This enhancement helps improve security by ensuring that the content you fetch from HTTP sources matches your expectations, similar to the content verification available with the git resolver using commit hashes and the bundle resolver using digests.

SRVKP-8511

Resolver caching reduces API calls and helps prevent rate limit errors

With this update, OpenShift Pipelines supports caching for bundle, git, and cluster resolvers. This reduces redundant fetches of remote resources and helps prevent API rate limit errors when executing pipelines. The cache operates in three modes:

• always - cache all resources
• never - disable caching

• auto - cache only immutable references such as git SHAs and digest-based bundles

  The default mode is auto. You can configure cache behavior globally through resolver config maps or override it per task using the cache parameter.

  SRVKP-7037

Array values are supported in when expressions

With this update, array values can be resolved in the input attribute of when expressions, enabling more flexible conditional logic in pipelines.

SRVKP-11214

Step display names improve pipeline readability

With this update, step objects support a displayName field, helping improve pipeline readability and monitoring.

SRVKP-11214

Pipelines can execute embedded pipelines

With this update, pipelines can execute embedded pipelines directly using the PipelineSpec field under tasks, enabling pipelines-in-pipelines functionality.

SRVKP-11214

Concurrent StepAction resolution reduces TaskRun startup time

With this update, StepActions in a TaskRun are resolved concurrently instead of sequentially, reducing startup time when using multiple remote StepActions.

SRVKP-11214

PipelineRuns handle PVC quota limits with resilience

With this update, when persistent volume claim (PVC) creation hits a quota limit, the PipelineRun is requeued until quota becomes available or the run times out, instead of failing immediately.

SRVKP-11214

Per-task timeout overrides in PipelineRun

With this update, individual task timeouts can be overridden at the PipelineRun level using the spec.taskRunSpecs[].timeout field.

SRVKP-11214

Operator

ServiceMonitor configuration for Results and Pipelines components

With this update, the OpenShift Pipelines Operator creates ServiceMonitor resources for the Tekton Results and tekton-pipelines-webhook components. This enables the Prometheus Operator to automatically discover their metrics endpoints, simplifying integration with OpenShift monitoring and alerting.

SRVKP-7683

Pipelines as Code

Caching changed files to reduce VCS API load

With this update, Pipelines as Code caches the list of changed files per event. This reduces redundant VCS API calls when evaluating path.pathChanged() or on-path-change annotations, helping minimize the risk of hitting API rate limits.

SRVKP-9228

Update comment strategy for GitLab and GitHub

With this update, Pipelines as Code introduces a new comment strategy named update for GitLab and GitHub webhooks. Instead of posting multiple comments per PipelineRun, the system maintains a single status comment. When the pipeline status changes or the run is re-executed, the existing comment is updated with the new status and commit SHA. This helps reduce comment noise and improve repository readability.

SRVKP-9998

Commit message tags to skip pipeline execution

With this update, pipeline executions can be skipped using specific commit message tags. Supported, case-insensitive tags include:

• [skip ci]
• [ci skip]
• [skip tkn]

• [tkn skip]

  This prevents unnecessary pipeline executions for minor or work-in-progress commits.

  Important

  When using [skip ci] or [ci skip] commands in commit messages on GitLab, one additional pipeline entry appears for the same commit SHA in the GitLab UI. This is expected behavior on GitLab, which uses the skip commands to skip any GitLab CI regardless of whether a .gitlab-ci.yml file is defined.

  SRVKP-11542

SRVKP-8933

Glob pattern support for GitHub App token scoping

With this update, Pipelines as Code supports glob patterns when specifying repositories for GitHub App token scoping. You can use wildcard patterns, such as my-org/*, in both global config maps and repository-level configurations. Users managing many private Git submodules can grant token access to all relevant repositories in a single configuration step.

The following example shows glob pattern usage in a global config map:

apiVersion: v1
kind: ConfigMap
metadata:
  name: pipelines-as-code
  namespace: pipelines-as-code
data:
  secret-github-app-scope-extra-repos: "owner2/project2, owner3/*"
# ...

The following example shows glob pattern usage in a Repository custom resource:

apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
kind: Repository
metadata:
  name: test
  namespace: test-repo
spec:
  url: "https://github.com/linda/project"
  settings:
    github_app_token_scope_repos:
    - "owner/project"
    - "owner1/*"
# ...

SRVKP-10030

Webhook signature validation for Forgejo and Gitea providers

With this update, Pipelines as Code enforces webhook signature validation for Forgejo and Gitea providers. Previously, the provider implementation skipped validation, which could allow unauthenticated or spoofed requests to trigger pipelines. With this release, the system verifies that incoming requests originate from trusted sources.

SRVKP-10609

CEL expressions are supported in pipeline templates

With this update, Pipelines as Code supports the cel: prefix for evaluating Common Expression Language (CEL) expressions directly within pipeline templates. Previously, template variables were limited to simple data extraction from the request body, headers, or files. You can use the cel: prefix to perform inline logic, including ternary operators, presence checks, and complex string compositions. The body, headers, files, and pac namespaces are exposed to the CEL evaluation engine.

For example, the following expression conditionally selects a commit ID based on the presence of parent commits:

{{ cel: has(body.toCommit) && body.toCommit.parents.size() > 1 ? body.toCommit.parents[1].id : body.toCommit.id }}

SRVKP-9979

Optimized GitHub API calls help improve .tekton file retrieval performance

With this update, Pipelines as Code uses the GitHub GraphQL API to fetch multiple .tekton configuration files in a single batched request instead of making individual REST API calls. This reduces the number of GitHub API calls and helps improve performance when discovering pipeline definitions on both GitHub and GitHub Enterprise instances.

SRVKP-11470

User interface

ANSI color support in the OpenShift console log viewer

With this update, the log viewer in the OpenShift console supports ANSI color codes for TaskRun and PipelineRun logs, helping improve readability.

SRVKP-10407

Multi-cluster

Multi-cluster configuration in TektonConfig (Technology Preview)

With this update, the TektonConfig custom resource includes new multi-cluster configuration fields in the scheduler section. This enables configuration of multi-cluster setups for OpenShift Pipelines. You can set multi-cluster-disabled to enable or disable multi-cluster mode and specify the multi-cluster-role as either Hub or Spoke.

# ...
scheduler:
  config.yaml:
    cel: {}
    queueName: pipelines-queue
  disabled: false
  multi-cluster-disabled: false
  multi-cluster-role: Hub
  options: {}
# ...

SRVKP-8979

Automatic scaling for Tekton Results in multi-cluster Hub mode (Technology Preview)

With this update, when the OpenShift Pipelines Operator is configured with multi-cluster-disabled=false and multi-cluster-role=Hub, the replicas of tekton-results-watcher and tekton-results-retention-policy-agent deployments are set to zero. These components run only on Spoke clusters, where local data fetching and retention occur, reducing resource usage on the Hub cluster without affecting the centralized Results API.

SRVKP-8983

Tekton Scheduler installation using the OpenShift Pipelines Operator (Technology Preview)

With this update, the OpenShift Pipelines Operator supports installation and management of the Tekton Scheduler (Tekton-Kueue). A new scheduler section in the TektonConfig CR allows enabling the scheduler and specifying a default queue name.

The integration supports multi-cluster configurations with multi-cluster-disabled and multi-cluster-role. Administrators can manage pipeline resource allocation and queuing across single or multiple OpenShift Container Platform clusters.

The upstream Kueue component must be installed for the Tekton Scheduler to function.

SRVKP-10005

Visual indicator for federated PipelineRuns in the multi-cluster UI (Technology Preview)

With this update, the multi-cluster user interface (UI) includes an icon to differentiate between a PipelineRun object running on the local hub cluster and a federated PipelineRun. The UI determines this by evaluating the managedBy field within the PipelineRun resource.

SRVKP-10807

User interface

Pipelines console navigation and plugin integration update

With this update, the legacy static console plugin is fully deprecated. Previously, a limited Pipelines navigation entry appeared even when the console plugin was disabled. This behavior is no longer supported.

You must explicitly enable the console plugin to access the Pipelines section in the OpenShift console.

SRVKP-9456

buildah-ns task fails on OpenShift Container Platform 4.20 and later

When you use the buildah-ns task on OpenShift Container Platform 4.20 and later, the task fails with the error reading ID mappings from "/proc/0/uid_map": open /proc/0/uid_map: no such file or directory. This occurs because the CRI-O annotation-based user namespace mechanism using io.kubernetes.cri-o.userns-mode: "auto" was removed in OpenShift Container Platform 4.20 due to upstream Kubernetes changes. As a consequence, the buildah-ns task cannot enable user namespaces using the annotation-based approach.

To work around this issue, use the standard buildah task and configure hostUsers: false in the PodTemplate field to enable user namespace support via the Kubernetes-native mechanism available on OpenShift Container Platform 4.20 and later.

SRVKP-9256

tkn CLI has limited functionality in multicluster environments

When using the tkn CLI tool in a multicluster setup, several commands do not work correctly. As a consequence, the following commands fail or produce incorrect results on the Hub cluster because task runs are executed on Spoke clusters:

• tkn taskrun list
• tkn pipelinerun describe
• tkn pipelinerun logs

• tkn pipelinerun cancel

  Additionally, on Spoke clusters, tkn pipelinerun list and tkn taskrun list only work while pipeline runs are still running, as completed runs are garbage collected immediately and no longer appear in the list.

SRVKP-10629

opc results logs get command limits output to 300 lines

When using the opc results logs get command to retrieve logs, the output is limited to 300 lines regardless of the actual log length. As a consequence, you cannot view complete logs for pipeline runs or task runs that generate more than 300 lines of output.

To work around this issue, use the opc results pipelinerun logs or opc results taskrun logs commands instead. These commands provide complete log output. The opc results logs get command might be deprecated in a future release.

SRVKP-11362

Pipelines

Affinity Assistant pods inherit correct service account

Before this update, when the affinity assistant was enabled to co-schedule tasks sharing workspace volumes, Affinity Assistant pods used the default service account instead of the service account configured in the PipelineRun. In security-restricted environments, the default service account lacked the necessary Security Context Constraints (SCC) permissions. As a consequence, tasks requiring workspace access would not start, causing the PipelineRun to block. With this update, Affinity Assistant pods inherit the service account from the PipelineRun’s taskRunTemplate by default. As a result, Affinity Assistant pods have the correct permissions, and PipelineRuns using workspaces run successfully without requiring manual SCC configuration.

SRVKP-7327

Misconfigured TaskRun pods fail early with clear error messages

Before this update, when a TaskRun pod could not start due to misconfiguration such as a missing config map or secret, the task run timed out silently with a generic timeout message. As a consequence, you could not identify the root cause of the failure, making debugging difficult. With this update, task runs with pod configuration errors fail immediately with a clear error message indicating the specific issue, such as missing resources. As a result, you can identify and resolve pod configuration problems without waiting for timeout periods.

SRVKP-9987

Pipeline runs without timeouts no longer cause excessive reconciliation

Before this update, when you did not configure a timeout on a task run or pipeline run, the controller reconciled the run thousands of times continuously while in progress. As a consequence, this caused excessive CPU usage on the controller, increased latency for other operations, and impacted cluster performance and scalability. With this update, the reconciliation logic correctly handles runs without timeout configurations. As a result, reconciliation occurs only when there are actual changes to the run or its child resources, helping improve controller performance and cluster stability.

SRVKP-9988

Pipeline parameter defaults correctly resolve references to other parameters

Before this update, when you defined a pipeline parameter default value that referenced another parameter, such as default: $(params.registry)/app, the parameter was not resolved and the literal string was used instead. As a consequence, task pod creation failed, and you could not use fallback patterns in pipelines and tasks. With this update, parameter resolution supports arbitrary dependency chains for all parameter types, including string, array, and object, and notation styles such as params.X, params["X"], and params['X']. Circular dependencies are detected and reported with clear error messages. As a result, you can define parameter defaults that reference other parameters, enabling flexible fallback patterns in your pipelines.

SRVKP-9989

PipelineRuns correctly handle TaskRef reconciliation errors

Before this update, PipelineRuns failed when TaskRef reconciliation encountered retryable errors. As a consequence, pipelines failed unnecessarily due to transient issues. With this update, PipelineRuns fail only on explicit validation errors and retry on retryable errors. As a result, pipelines are more resilient to temporary issues.

SRVKP-11214

Kubernetes-native sidecars correctly handle signals

Before this update, Kubernetes-native sidecars experienced issues with repeated init container restarts due to improper signal handling. With this update, the controller adds signal handling to SidecarLog results. As a result, sidecars operate more reliably.

SRVKP-11214

TaskRun pods are retained when timeouts occur with keep-pod-on-cancel enabled

Before this update, the controller did not retain pods for timed-out TaskRuns when the keep-pod-on-cancel feature flag was enabled. As a consequence, debugging information was lost. With this update, the controller retains pods when the flag is enabled. As a result, you can inspect pods for timed-out task runs.

SRVKP-11214

StepAction status displays in the correct order

Before this update, status steps displayed in incorrect order when using StepAction. As a consequence, monitoring and debugging were more difficult. With this update, the controller displays status steps in the correct order. As a result, task execution flow is easier to understand.

SRVKP-11214

Task runs execute successfully on arm64 Kubernetes clusters

Before this update, arm64 Kubernetes clusters experienced task run failures due to platform variant mismatch in entrypoint lookup. As a consequence, tasks failed on arm64 clusters. With this update, the entrypoint correctly handles Linux platform variants. As a result, task runs succeed on arm64 clusters.

SRVKP-11214

Pipeline run status updates reduce API server load

Before this update, unordered arrays in pipeline run status caused massive invalid status updates, impacting API server load and stability. As a consequence, cluster performance degraded. With this update, the controller ensures consistent array ordering. As a result, API server load is reduced and cluster stability improves.

SRVKP-11214

Operator

Webhooks are properly cleaned up when the Operator namespace is deleted

Before this update, the proxy.operator.tekton.dev, validation.pipelinesascode.tekton.dev, and namespace.operator.tekton.dev webhooks lacked owner references to the openshift-pipelines namespace. As a consequence, when you uninstalled the Pipelines Operator by deleting the namespace, these webhooks were not removed and remained on the cluster. With this update, owner references are added to all operator webhooks. As a result, all webhooks are properly cleaned up when you uninstall the Operator.

SRVKP-8901

Prometheus metrics collection works when the Operator is installed in a custom namespace

Before this update, the Operator ServiceMonitor resource had a hardcoded namespace reference to openshift-operators in its namespace selector. As a consequence, when you installed the Pipelines Operator in a different namespace, such as openshift-pipelines, Prometheus attempted to scrape metrics from the wrong namespace, causing permission errors and triggering the PrometheusKubernetesListWatchFailures alert. With this update, the hardcoded namespace reference is removed, and the ServiceMonitor automatically targets the namespace where the Operator is installed. As a result, Prometheus metrics collection works correctly regardless of the namespace where you install the Operator.

SRVKP-10509

Pipelines as Code

Custom parameters are supported in CEL expressions correctly

Before this update, custom parameters defined in the Repository custom resource (CR) were not recognized in on-cel-expression annotations. This resulted in "undeclared reference" errors for custom parameters and, in some cases, standard variables such as event_type. As a result, repository-specific parameters could not be used for event filtering. With this update, custom parameters are exposed as Common Expression Language (CEL) variables and can be referenced directly in CEL expressions. Standard CEL variables take precedence if a naming conflict occurs.

For example, with this Repository CR configuration:

apiVersion: pipelinesascode.tekton.dev/v1alpha1
kind: Repository
metadata:
  name: my-repo
spec:
  url: "https://github.com/owner/repo"
  params:
    - name: enable_ci
      value: "true"
    - name: environment
      value: "staging"

You can use these parameters directly in your PipelineRun CEL expression:

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: my-pipeline
  annotations:
    pipelinesascode.tekton.dev/on-cel-expression: |
      event == "push" && enable_ci == "true" && environment == "staging"
spec:
  # ...

SRVKP-10082

Commit messages containing "[skip ci]" are respected in GitLab merge requests

Before this update, commit messages containing "[skip ci]" were not honored by the GitLab provider, and PipelineRun resources were created despite the skip directive. This behavior caused unnecessary pipeline executions. With this update, the GitLab integration correctly detects and respects skip directives in commit messages.

SRVKP-10440

Non-HTTP(S) pipeline URLs no longer cause "invalid port" errors

Before this update, custom hub catalog references that included version specifiers (for example, foo://resource:1.2) could cause an "invalid port" error. The Go url.Parse() function interpreted the version delimiter as a port separator, which caused pipeline resolution to fail. With this update, non-HTTP(S) schemes are excluded from URL parsing in task resolution logic, allowing versioned custom catalog references to function correctly.

SRVKP-10880

The tkn pac cel command enforces required flags and provides clearer errors

Before this update, running the tkn pac cel command without the required body (-b) and header (-H) flags produced misleading error messages such as "auto-detection failed" or "unexpected end of JSON input." With this update, both flags are mandatory, and the command returns a clear error message when required arguments are missing.

SRVKP-9400

The pull_request_number variable is more reliably populated for push events

Before this update, Pipelines as Code occasionally failed to identify pull request numbers during push events associated with a pull request merge. This occurred primarily when using the merge commit strategy, as GitHub API indexing delays prevented the immediate association of a commit with a pull request. As a consequence, the pull_request_number variable was not populated, causing intermittent failures for subsequent tasks. With this update, an exponential backoff retry mechanism is implemented to detect merge commits and retry the API call. As a result, the pull_request_number variable is correctly populated even when there is minor provider latency.

SRVKP-9474

GitLab push events evaluate all modified files for trigger filtering

Before this update, when processing GitLab push events, the files CEL variable and the pathChanged() method evaluated only the first 20 modified files because API pagination was not implemented. Pipelines relying on file-based filtering might not have triggered if relevant changes were beyond that limit. With this update, all modified files from the GitLab API are retrieved and evaluated during CEL execution.

SRVKP-9708

GitLab commit statuses correctly reflect pipeline state

Before this update, when a forked merge request required /ok-to-test approval, GitLab displayed a "running" status instead of "pending." Additionally, the parent status entry was not updated as the pipeline progressed. With this update, the GitLab provider correctly maps pending states and updates parent status entries throughout the pipeline lifecycle.

SRVKP-9459

GitLab merge request comments are limited to permission failures

Before this update, a comment was posted to a GitLab merge request whenever a commit status update failed, regardless of the error type. This behavior could produce misleading "pipeline run started" comments. With this update, a fallback comment is posted only when the commit status update fails due to permission errors.

SRVKP-9442

The tkn pac cel command handles invalid GitLab input safely

Before this update, running tkn pac cel -p gitlab with malformed payloads or headers could cause a nil pointer dereference panic. With this update, input validation is performed before processing GitLab data, and the command returns a descriptive error instead of panicking.

SRVKP-9396

Commit-level re-evaluation of /ok-to-test approvals is enforced

Before this update, when the remember-ok-to-test parameter was set to false, a single /ok-to-test approval from an unauthorized user was incorrectly retained for subsequent commits in the same pull request. This behavior could allow unreviewed changes to execute in CI. With this update, permissions are re-evaluated for each new commit when remember-ok-to-test=false, and CI execution is blocked until a repository administrator provides approval.

SRVKP-9200

Skipped push events are logged at the correct level

Before this update, intentionally skipped push events were logged at the error level when the commit was associated with an open pull request. This behavior caused confusion during troubleshooting. With this update, these events are logged at the info level to reflect expected behavior.

SRVKP-8909

Bitbucket Cloud displays individual status for each pipeline run triggered by push events

Before this update, when multiple pipeline runs were triggered in a pull request in Bitbucket Cloud, Pipelines as Code used a static key when reporting commit statuses. Each subsequent pipeline run overwrote the previous status. As a consequence, only one build status was visible in Bitbucket Cloud, and you could not determine which individual pipeline run succeeded or failed. With this update, Pipelines as Code uses a unique commit status key for each pipeline run in the format "ApplicationName / PipelineRunName". As a result, each pipeline run reports its status individually to Bitbucket Cloud, allowing you to view results for all triggered pipeline runs.

SRVKP-9636

CEL expressions correctly evaluate pull request label events

Before this update, on-cel-expression annotations were not evaluated during pull request labeling events unless an on-label annotation was also present. Pipelines designed to trigger based on label conditions did not start when labels were added. With this update, Abstract Syntax Tree (AST) inspection detects label references within CEL expressions, ensuring correct evaluation during labeling events.

SRVKP-8491

Deleted or canceled PipelineRun resources update Git provider commit status

Before this update, PipelineRuns deleted while in a Running or Queued state remained stuck as pending on Git providers. As a consequence, commit statuses could remain in a pending state indefinitely in the Git provider UI. With this update, the Pipelines as Code finalizer explicitly reports a canceled status to the Git provider when a PipelineRun is deleted. As a result, Git provider UIs accurately reflect the terminated lifecycle of the PipelineRun.

SRVKP-8318

User interface

Pipeline run logs preserve whitespace and formatting in the console

Before this update, pipeline run logs in the OpenShift Container Platform console did not preserve whitespace, and long lines were automatically wrapped. Structured log output and tabular data appeared misaligned, which reduced readability. With this update, the log viewer preserves whitespace and provides horizontal scrolling for long lines.

SRVKP-10035

TaskSidebar displays correctly in the Pipeline Builder

Before this update, the TaskSidebar in the Pipeline Builder lacked a required styling property. As a consequence, the sidebar rendered behind other page elements, with only the header visible. With this update, the required styling is applied to the TaskSidebar component. As a result, the sidebar correctly overlays other components and remains accessible.

SRVKP-11533

The openshift-pipelines-client RPM is deprecated

The openshift-pipelines-client RPM is deprecated and might be removed in the Pipelines 1.23 release.

SRVKP-9444

The pipelinerun_status field in the Repository CR is deprecated

The pipelinerun_status field in the Repository custom resource (CR) is deprecated and might be removed in the Pipelines 1.23 release.

SRVKP-9223

The disable-affinity-assistant field is removed from TektonConfig

The disable-affinity-assistant field in the TektonConfig custom resource spec.pipeline section is removed. This field was deprecated in favor of the coschedule feature flag and had no effect since Pipelines 1.0.0. If you previously used the disable-affinity-assistant field, migrate to the coschedule feature flag to control affinity assistant behavior.

SRVKP-8267

Public Tekton Hub is removed as a default built-in catalog

The public Tekton Hub (hub.tekton.dev), which served as a default built-in catalog for pipeline resources, is removed and is no longer supported. You can use custom self-hosted Tekton Hub instances instead.

SRVKP-11213