Operator

Self-healing for CA bundle config maps in user namespaces

The OpenShift Pipelines Operator automatically detects and recreates missing CA bundle config maps (config-trusted-cabundle and config-service-cabundle) in user namespaces. Previously, if these config maps were deleted after initial reconciliation, the Operator would not recreate them because it only checked the namespace label. The Operator verifies that both config maps exist and triggers re-reconciliation if either is missing.

This content is not included.SRVKP-10928

Central TLS profile consistency for OpenShift Pipelines components

OpenShift Pipelines respects central TLS consistency on OpenShift Container Platform by default. All TLS-enabled services inherit the cluster APIServer TLS security profile, including minimum TLS version and cipher suites, on the next reconcile after upgrade. This includes the Operator webhooks, Pipelines webhook, Triggers webhook and core interceptors, Pipelines as Code webhook, Manual Approval Gate webhook, and console plugin nginx server. Changes to the cluster TLS profile are automatically propagated to components without operator restarts, enabling Post-Quantum Cryptography (PQC) readiness. You can set the enableCentralTLSConfig setting to false in TektonConfig to opt out.

This content is not included.SRVKP-9462

Metrics migrated from OpenCensus to OpenTelemetry

Metrics across all OpenShift Pipelines components (Operator, Pipelines, Triggers, Tekton Chains, Tekton Results, and Pipelines as Code) are migrated from OpenCensus to OpenTelemetry. Infrastructure metrics such as workqueue, Kubernetes client, and Go runtime metrics are renamed from component-specific prefixes to standard Knative and OpenTelemetry namespaces. The configuration key changes from metrics.backend-destination to metrics-protocol in the following config maps: tekton-config-observability (Operator), config-observability (Pipelines), config-observability-triggers (Triggers), and tekton-results-config-observability (Tekton Results). Pipelines as Code migrates from the K_METRICS_CONFIG environment variable to a ConfigMap-based configuration using pipelines-as-code-config-observability. Tekton Chains signing metric names remain unchanged.

The following tables list the breaking metric changes. Core application metrics such as tekton_pipelines_controller_pipelinerun_duration_seconds and Tekton Chains signing metrics remain unchanged.

Table 1.2. Infrastructure metric renames (all components)

Old metric name	New metric name
tekton_pipelines_controller_workqueue_adds_total	kn_workqueue_adds_total
tekton_pipelines_controller_workqueue_depth	kn_workqueue_depth
tekton_pipelines_controller_workqueue_queue_latency_seconds	kn_workqueue_queue_duration_seconds
tekton_pipelines_controller_workqueue_work_duration_seconds	kn_workqueue_process_duration_seconds
tekton_pipelines_controller_workqueue_retries_total	kn_workqueue_retries_total
tekton_pipelines_controller_workqueue_unfinished_work_seconds	kn_workqueue_unfinished_work_seconds
tekton_pipelines_controller_client_latency	http_client_request_duration_seconds
tekton_pipelines_controller_client_results	kn_k8s_client_http_response_status_code_total
tekton_pipelines_controller_go_*	go_*
tekton_pipelines_controller_reconcile_count	kn_workqueue_adds_total
tekton_pipelines_controller_reconcile_latency	kn_workqueue_process_duration_seconds

Note

Other components follow the same rename pattern. For example, the Triggers controller_workqueue_depth metric changes to kn_workqueue_depth.

Table 1.3. Counter suffix changes (Triggers, Tekton Results, and Pipelines as Code)

Old metric name	New metric name	Component
eventlistener_event_received_count	eventlistener_event_received_total	Triggers
eventlistener_triggered_resources	eventlistener_triggered_resources_total	Triggers
watcher_pipelinerun_delete_count	watcher_pipelinerun_delete_count_total	Tekton Results
watcher_taskrun_delete_count	watcher_taskrun_delete_count_total	Tekton Results
runs_not_stored_count	watcher_runs_not_stored_count_total	Tekton Results
pipelines_as_code_pipelinerun_count	pipelines_as_code_pipelinerun_count_total	Pipelines as Code
pipelines_as_code_pipelinerun_duration_seconds_sum	pipelines_as_code_pipelinerun_duration_seconds_sum_total	Pipelines as Code
pipelines_as_code_git_provider_api_request_count	pipelines_as_code_git_provider_api_request_count_total	Pipelines as Code

Table 1.4. Removed Operator metrics

Removed metric	Type
tekton_operator_lifecycle_pipeline_reconcile_total	Counter
tekton_operator_lifecycle_trigger_reconcile_total	Counter
tekton_operator_lifecycle_chains_reconciled_total	Counter
tekton_operator_lifecycle_results_reconciled	Gauge

Table 1.5. Configuration key changes

Config map	Old key	New key
tekton-config-observability (Operator)	metrics.backend-destination	metrics-protocol
config-observability (Pipelines)	metrics.backend-destination	metrics-protocol
config-observability-triggers (Triggers)	metrics.backend-destination	metrics-protocol
tekton-results-config-observability (Tekton Results)	metrics.backend-destination	metrics-protocol
pipelines-as-code-config-observability (Pipelines as Code)	K_METRICS_CONFIG environment variable	CONFIG_OBSERVABILITY_NAME ConfigMap reference

Important

If you customized observability settings, you must update the configuration key from metrics.backend-destination to metrics-protocol in your tekton-config-observability, config-observability, config-observability-triggers, or tekton-results-config-observability config maps. For Pipelines as Code, you must migrate from the K_METRICS_CONFIG environment variable to the pipelines-as-code-config-observability config map. Update any dashboards or alerts that reference the renamed or removed metrics.

This content is not included.SRVKP-7899

Pipelines

Hub Resolver supports multiple Artifact Hub URLs

The Hub Resolver supports multiple Artifact Hub URLs at the cluster level with ordered fallback behavior. Previously, only a single URL could be configured cluster-wide. Multiple hub URLs can be configured at the cluster level, or a hub URL can be specified per resolution request using the url parameter. When no parameter is provided, the resolver falls back to cluster defaults.

This content is not included.SRVKP-10955

TaskRun pending status

TaskRuns support spec.status: TaskRunPending to hold execution before Pod creation. Previously, task runs did not have parity with pipeline runs for pending execution. Clearing the field starts execution.

Workspace PVC cleanup

PipelineRuns that use coschedule: workspaces can opt in to automatic cleanup of generated PVCs with the tekton.dev/auto-cleanup-pvc: "true" annotation. Previously, PVCs created from volumeClaimTemplate workspaces were not automatically cleaned up after pipeline run completion. User-provided PVCs are not affected.

Specific TaskRun failure reasons

TaskRun status reports more specific reasons such as PodEvicted, InitContainerOOM, InitContainerFailed, StepOOM, StepFailed, SidecarOOM, and SidecarFailed. Previously, pod-level task run failures were often reported with a generic Failed reason, requiring inspection of Pod details to understand common failure causes.

TaskRun pod latency metric changes

taskruns_pod_latency_milliseconds is exported as a Histogram without the pod label. Previously, this metric was exported as a Gauge and included a pod label. Dashboards and alerts that use this metric must use histogram_quantile() instead of direct value queries.

CloudEvents delivery moves to events controller

CloudEvents are sent by the dedicated tekton-events-controller. Previously, pipeline run and task run controllers sent CloudEvents directly. Operators must ensure that the tekton-events-controller Deployment is running.

CustomRun CloudEvents enabled by default

CloudEvents for CustomRuns are sent by default when a sink is configured. Previously, the send-cloudevents-for-runs feature flag defaulted to false. The flag is deprecated and defaults to true.

Pipelines as Code

Configurable prefix for GitOps commands prevents CI conflicts

Pipelines as Code supports a configurable prefix for GitOps commands to prevent conflicts when multiple CI systems are active on the same repository. You can define a custom prefix, for example, /pac retest instead of /retest. The controller only triggers for its designated instructions.

This content is not included.SRVKP-7197

Custom User-Agent header for Gitea and Forgejo API requests

Pipelines as Code supports configurable custom User-Agent headers for API requests to Gitea and Forgejo instances. You can define a custom User-Agent string in the Repository custom resource or through global configuration to communicate with instances protected by proxies that require a specific User-Agent.

This content is not included.SRVKP-10579

Remote task resolution for Gitea and Forgejo

Pipelines as Code supports resolving remote taskRef URLs when using Gitea or Forgejo as your Git provider. Previously, the provider silently ignored URL-based task references. You can reference tasks stored in any Gitea or Forgejo repository using standard web URLs, and Pipelines as Code fetches them using authenticated API calls. Supported URL formats include branch, tag, and commit SHA references. Both /src/ and /raw/ URL styles are accepted.

This content is not included.SRVKP-10610

Consolidated GitHub App token and JWT creation helps improve reliability

Pipelines as Code consolidates the GitHub App authentication flow by centralizing token and JWT creation logic. Previously, JWT generation logic was duplicated across multiple code paths, causing redundant Kubernetes API calls. The consolidated implementation reduces API load and helps improve the reliability of GitHub App authentication.

This content is not included.SRVKP-10952

Centralized pull request data fetching reduces GitHub API calls

Pipelines as Code caches GitHub pull request information within a single event lifecycle, eliminating redundant API calls. Previously, different code section for different events independently fetched the same pull request data from the GitHub API. The centralized approach fetches pull request metadata once and makes it available to all sections. As a result, event processing is faster and API rate limit consumption is reduced.

This content is not included.SRVKP-11121

Check run lookups are cached to reduce duplicate GitHub API calls

Pipelines as Code caches GitHub check run lookups during event processing. Previously, repositories with multiple PipelineRun definitions in the .tekton directory made redundant API calls to get the list of check runs, consuming rate limit unnecessarily. With this update, the check run list is fetched once and shared across all PipelineRun resources in the same event. As a result, GitHub API rate limit usage is significantly reduced.

This content is not included.SRVKP-11568

Informer cache memory usage reduces by stripping unnecessary fields

Pipelines as Code strips large unused fields from cached objects in its informer caches, reducing per-object memory consumption by up to 94%. Previously, full Repository and PipelineRun objects were held in memory including fields only needed during active processing. With this update, only the metadata required for event matching is cached, and full object data is fetched from the API when needed.

This content is not included.SRVKP-11061

GitLab /retest command uses commit status fallback when PipelineRuns are pruned

The /retest command on GitLab falls back to fetching commit statuses directly from the GitLab API when PipelineRun data is unavailable due to pruning. Previously, when PipelineRun objects were pruned from the cluster, the /retest command could not determine which pipelines had already succeeded. As a consequence, all pipelines were re-run. Pipelines as Code fetches commit statuses from GitLab when PipelineRun objects are not found, allowing the /retest command to skip previously successful pipelines. As a result, only failed pipelines are re-run.

This content is not included.SRVKP-11112

Configurable comment update strategy for GitHub

Pipelines as Code supports configuring a single status comment per pipeline run on GitHub instead of posting a new comment on each re-execution to reduce comment noise on pull requests.

Configurable comment update strategy for GitLab

Pipelines as Code supports updating a single status comment per pipeline run on GitLab merge requests instead of posting a new comment on every trigger to reduce comment noise.

Configurable comment update strategy for Gitea

The Gitea provider supports configurable comment update strategies to control how status comments are managed on pull requests.

Gitea provider caches changed files

The Gitea provider caches changed files to reduce redundant API calls during pipeline runs, helping improve performance for repositories with frequent triggers.

Informative message when /retest has nothing to retest

When issuing /retest with no failed PipelineRuns to retry, Pipelines as Code responds with an informative message.

Tekton Chains

Server-Side Apply helps improve finalizer management for resource cleanup

Tekton Chains uses Kubernetes Server-Side Apply to manage finalizers on TaskRun and PipelineRun resources. This helps improve the reliability and performance of resource cleanup by preventing conflicts when multiple controllers manage the same resources during deletion.

This content is not included.SRVKP-8542

Insecure OCI registry support

Tekton Chains supports connecting to insecure OCI registries. This allows signing and storing attestations in registries that do not have valid TLS certificates, such as development or testing environments.

Tekton Results

Loki logging plugin configuration options

Two new Loki-specific configuration options are available for the logging plugin: LOGGING_PLUGIN_JSON_MAP to define custom JSON field extraction mappings, and LOGGING_PLUGIN_LINE_FORMAT to define custom log line output formatting. This allows extraction of structured fields from Loki log entries, such as timestamps and pipeline run UIDs, and control over how log lines are displayed when queried through Tekton Results.

Tasks

Maven Task supports Java version selection

The Maven Task includes a new JAVA_VERSION parameter to select the Java version for Maven builds. Supported values are 8, 11, 17, and 21. Previously, the Java version was hard-coded to OpenJDK 11. This was a regression from the ClusterTask-to-Task migration in OpenShift Pipelines 1.17. The default value remains 11 for backward compatibility.

This content is not included.SRVKP-10806

Operator

Operator webhooks deleted before namespace cleanup on uninstall

Before this update, operator admission webhooks (namespace.operator.tekton.dev and proxy.operator.tekton.dev) could remain registered while their backend service was already removed during uninstall. As a consequence, TektonConfig finalization could fail, leaving the Subscription, ClusterServiceVersion, and operator deployment behind in the openshift-operators namespace. With this update, webhooks are explicitly removed at the start of finalization before namespace label cleanup runs. As a result, the OpenShift Pipelines Operator uninstalls cleanly through the OpenShift Container Platform web console.

Tekton Results API route uses passthrough TLS termination

Before this update, the Tekton Results API route did not use passthrough TLS termination. As a consequence, end-to-end encryption between clients and the Results API service was not enabled. With this update, the Tekton Results API route uses passthrough TLS termination by default. As a result, end-to-end encryption is enabled for API communications.

TektonInstallerSet deadlock resolved when resources have deletionTimestamp

Before this update, a TektonInstallerSet could deadlock when attempting to reconcile resources that had a deletionTimestamp set. As a consequence, the reconciliation process could hang indefinitely. With this update, the reconciliation logic properly handles resources with deletionTimestamp. As a result, reconciliation completes successfully without deadlocking.

Pipelines

Git credential matching supports multiple repositories on the same host

Before this update, when multiple secrets were linked to a ServiceAccount for different repositories on the same Git server, such as github.com/org/repo1 and github.com/org/repo2, Git’s credential helper matched credentials based only on protocol and hostname, ignoring the repository path. As a consequence, Git always used the first matching credential for all repositories on that host, causing authentication failures for repositories requiring different credentials. With this update, Git credential contexts include useHttpPath = true, enabling the credential helper to match credentials based on the full repository URL including the path. As a result, you can use multiple repository-specific credentials on the same Git server, and each repository correctly uses its designated credentials.

This content is not included.SRVKP-9280

Git resolver path validation

Before this update, the git resolver did not fully validate pathInRepo values. As a consequence, invalid repository paths could be accepted. With this update, pathInRepo values are validated before use. As a result, directory traversal paths are rejected.

Git resolver revision validation

Before this update, the git resolver accepted revision values that could be interpreted as additional git command arguments. As a consequence, invalid revision input could affect git command execution. With this update, revision values are validated before they are passed to git. As a result, only valid revision values are accepted.

Git resolver API token handling

Before this update, git resolver API mode could use a system configured token with a user supplied serverURL. As a consequence, token use was not limited to the intended server. With this update, system configured tokens are rejected when the serverURL is user controlled. As a result, the resolver only uses those tokens with trusted configuration.

Resolver name validation

Before this update, an overly long resolver name in a TaskRun or PipelineRun could cause the controller to restart. As a consequence, invalid resolver names could disrupt reconciliation. With this update, resolver names are validated before reconciliation reaches the failing path. As a result, invalid resolver names are rejected safely.

VolumeMount path validation

Before this update, VolumeMount paths were checked without full path normalization. As a consequence, some invalid paths could bypass the /tekton/ restriction check. With this update, paths are normalized before the restriction check is applied. As a result, restricted paths are handled consistently.

VerificationPolicy pattern matching

Before this update, VerificationPolicy regular expressions could match substrings unexpectedly. As a consequence, policy checks could pass when only part of a value matched. With this update, resolver prefixes are stripped and matching is anchored. As a result, VerificationPolicy checks match the intended values.

HTTP resolver response size limit

Before this update, the HTTP resolver could read an unbounded response body. As a consequence, very large responses could exhaust resolver memory. With this update, HTTP resolver response bodies are capped at 1 MiB. As a result, large responses fail safely.

Pipeline results from unsuccessful tasks

Before this update, pipeline level results could miss results produced by failed, cancelled, or timed out tasks. As a consequence, available results from unsuccessful tasks could remain unresolved. With this update, pipeline level results include available results from those tasks. As a result, pipeline run results are recorded more consistently.

PipelineRun timeout propagation

Before this update, PipelineRun spec.timeouts.tasks and spec.timeouts.finally were not propagated to child TaskRuns that lacked an explicit per-task timeout. As a consequence, child TaskRuns could time out earlier than the PipelineRun intended. With this update, child TaskRuns inherit the appropriate timeout values. As a result, PipelineRun task and finally timeouts are honored correctly.

Credential volume name collisions avoided

Before this update, namespaces with many annotated secrets could produce credential volume name collisions. As a consequence, task runs could fail when generated volume names collided. With this update, credential volume names use deterministic hashing. As a result, credential volume name collisions are avoided.

Cross architecture entrypoint lookup

Before this update, mixed architecture clusters could fail entrypoint command lookup when controller and worker nodes used different CPU architectures. As a consequence, workloads could fail on a worker architecture that differed from the controller architecture. With this update, platform command lookup uses the worker platform correctly. As a result, mixed architecture clusters are handled correctly.

Init container OOM handling

Before this update, a TaskRun could remain Running when an init container was OOMKilled with enableKubernetesSidecar enabled. As a consequence, users could see a TaskRun stuck in Running even though the Pod had failed. With this update, the TaskRun is marked Failed. As a result, the TaskRun status reflects the failed init container.

Pipelines as Code

GitHub App credentials protected from header injection attacks

Before this update, a forged HTTP header in a webhook request could trick Pipelines as Code into sending GitHub App credentials to an attacker-controlled server. When Pipelines as Code received a webhook, it read the X-GitHub-Enterprise-Host header to determine which GitHub Enterprise server to contact for authentication. This header was not verified, allowing an attacker to supply their own server address. As a consequence, Pipelines as Code would send a valid GitHub App installation token to the attacker’s server, potentially allowing the attacker to impersonate the Pipelines as Code application and access any repository where the GitHub App is installed. With this update, Pipelines as Code validates webhook requests to prevent GitHub App credentials from being sent to untrusted servers. As a result, GitHub App credentials are protected from header injection attacks.

Important

This is a critical security fix. Upgrade to this version or later as soon as possible.

This content is not included.SRVKP-12216

source_url parameter correctly reflects fork repository details after retest in Gitea and Forgejo

Before this update, when retesting pull requests using comments in Gitea or Forgejo, the source_url parameter could lose fork repository details, resulting in an empty or incorrect git-url value in the PipelineRun. As a consequence, pipelines could not clone the source code from the fork repository. With this update, the source_url parameter is correctly populated to reflect the original fork repository when a retest is initiated. As a result, pipelines can reliably fetch source code from Gitea and Forgejo fork repositories.

This content is not included.SRVKP-10575

GitLab merge requests exceeding diff limits evaluate file-based CEL expressions correctly

Before this update, when a GitLab merge request exceeded the GitLab instance’s diff limit, CEL expressions such as "some/path".pathChanged() did not evaluate against changed files beyond the diff limit. As a consequence, pipeline runs that relied on file-based matching could fail to trigger for large merge requests. With this update, Pipelines as Code detects when the diff is truncated and switches to using the GitLab Compare API to retrieve the full list of changes. As a result, file-based CEL expressions work correctly even when merge requests exceed GitLab’s diff limits.

This content is not included.SRVKP-10677

Comment ownership validation prevents editing comments from other users or bots

Before this update, Pipelines as Code identified comments to update using a regex marker pattern. If another user or bot posted a comment containing the same marker text, Pipelines as Code could attempt to edit that comment. As a consequence, this could overwrite legitimate user or bot comments, cause permission errors, or create confusion in pull request discussions. With this update, Pipelines as Code validates comment ownership before editing and only modifies comments created by the credentials used for the configured app or token. As a result, Pipelines as Code no longer accidentally edits or overwrites comments from other users or bots.

This content is not included.SRVKP-10857

Repository CR admission webhook validates URL path shape to prevent token scoping bypass

Before this update, Repository custom resource URLs with extra path segments, such as Content from github.com is not included.https://github.com/org/repo/extra, passed admission validation but were silently truncated to org/repo during GitHub App token scoping. As a consequence, malformed URLs could bypass namespace ownership guards and scope tokens to repositories not truly represented by a valid Repository custom resource. With this update, the admission webhook validates URL path shapes and rejects Repository custom resources with malformed GitHub URLs that include extra path segments beyond org/repo. The webhook also detects GitHub Enterprise instances and enforces the org/repo format. As a result, namespace-level isolation of GitHub App token scoping is properly enforced.

This content is not included.SRVKP-10943

Relative task path resolution restored for repository-based references

Before this update, a regression introduced in OpenShift Pipelines 1.20.3 prevented Pipelines as Code from correctly resolving relative task references within a repository, such as ./task.yaml or paths containing parent directory notation ... As a consequence, pipelines that modularized task definitions using relative paths in the .tekton directory failed to execute. With this update, the path normalization logic in the Git resolver is fixed to correctly handle relative path segments. As a result, pipelines can successfully reference and execute tasks using relative paths across all supported Git providers.

This content is not included.SRVKP-11021

LLM analysis supports newer OpenAI models using correct token parameter

Before this update, Pipelines as Code LLM analysis used the legacy max_tokens parameter when making requests to the OpenAI API. Newer OpenAI models such as gpt-5, o1, and o3 series reject this parameter and require max_completion_tokens instead. As a consequence, LLM analysis failed with HTTP 400 errors when using these newer models. With this update, Pipelines as Code detects the model type and sends the correct parameter. The configuration parameter for LLM analysis remains the same to maintain vendor neutrality. As a result, LLM analysis works correctly with both newer and older OpenAI-compatible models.

This content is not included.SRVKP-11464

LLM analysis respects CEL expressions for all pipeline run states

Before this update, Pipelines as Code LLM analysis only triggered for failed PipelineRun resources, even when the on_cel expression was configured to trigger on successful runs. The reconciler contained a hard-coded check that filtered out successful runs before evaluating the CEL expression. As a consequence, users could not generate automated summaries or change logs for successful deployments. With this update, the hard-coded failed-only check is removed and the decision is delegated to the LLM orchestrator. When no on_cel expression is defined, the orchestrator defaults to triggering only for failed PipelineRun resources to maintain backward compatibility. An explicit on_cel expression overrides this behavior. As a result, users can configure LLM analysis to trigger on successful, failed, or any other pipeline run state.

This content is not included.SRVKP-11465

Incoming webhooks populate default branch correctly

Before this update, when using incoming webhooks with pipelinerun_provenance: default_branch configured in the Repository custom resource, Pipelines as Code failed to populate the DefaultBranch field in the event payload. As a consequence, when Pipelines as Code attempted to fetch PipelineRun definitions from the default branch, the API call to the Git provider failed with a 404 error because an empty branch reference was sent. With this update, Pipelines as Code correctly populates the DefaultBranch field for incoming webhook events. As a result, incoming webhooks with pipelinerun_provenance: default_branch work correctly and fetch .tekton/ definitions from the repository’s default branch.

This content is not included.SRVKP-11511

OWNERS file ACL checks read from the correct target branch on GitHub

Before this update, when Pipelines as Code performed OWNERS file ACL authorization checks on GitHub, the file-fetch helper ignored the provided target ref and instead used the pull request base branch. As a consequence, when a pull request targeted a non-default branch and the OWNERS file differed between branches, ACL decisions could be made using the wrong OWNERS file content. This could potentially allow unauthorized users to trigger pipelines or block authorized ones. With this update, the GitHub provider correctly uses the requested target ref when reading the OWNERS file. As a result, OWNERS ACL checks evaluate the correct branch.

This content is not included.SRVKP-11527

Pending approval status resolves correctly after /ok-to-test on GitHub Webhook

Before this update, when using GitHub Webhook integration, an unauthorized user raising a pull request would trigger a pending check run requesting /ok-to-test approval from a repository admin. After the admin commented /ok-to-test, the pending check run remained stuck in a pending state indefinitely. As a consequence, the status check continued to display "Waiting for status to be reported — Pending approval, waiting for an /ok-to-test" even though the pull request was approved. With this update, the pending check run is properly transitioned to success when an admin approves the pull request with /ok-to-test. As a result, the approval workflow is correctly reflected in the pull request status checks.

This content is not included.SRVKP-11789

ACL checks handle nil responses and bounded pagination

Before this update, a nil HTTP response from the GitHub API on transport-level failures caused a panic during ACL checks, and comment pagination was unbounded. As a consequence, the controller could crash and make excessive API calls. With this update, nil responses are guarded and comment pagination is capped. As a result, the controller handles transport failures gracefully.

GitLab diff API pagination handles large merge requests

Before this update, GitLab’s diff API pagination limits could cause Pipelines as Code to miss changed files in large merge requests. As a consequence, on-path-change filters could skip pipeline runs. With this update, a workaround paginates through all diff pages. As a result, all changed files are detected even in large merge requests.

Label values sanitized for Kubernetes compliance

Before this update, Kubernetes label values derived from branch names were not sanitized to comply with the 63-character limit and valid character set rules. As a consequence, PipelineRuns with long or special-character branch names failed with label validation errors. With this update, label values are sanitized and normalized. As a result, branch names with dots, long names, and other special characters work correctly.

PipelineURL set for cached pipelines helps resolve relative task paths

Before this update, relative task references in cached pipelines failed to resolve because the PipelineURL was not set. As a consequence, PipelineRuns referencing relative task paths failed. With this update, the PipelineURL is set for cached pipelines. As a result, relative task paths resolve correctly.

Bitbucket Data Center group permission checks work correctly

Before this update, permission checking for Bitbucket Data Center groups did not work correctly due to a bug in the go-scm library. As a consequence, group-based access control rules were not enforced. With this update, go-scm is updated to v1.15.17 which resolves the permission checking bug. As a result, Bitbucket Data Center group-based access control works as expected.

Target namespace annotation respected for /test and /cancel comments

Before this update, the target-namespace annotation was not respected when explicit /test and /cancel GitOps commands were issued. As a consequence, PipelineRuns were created in the wrong namespace. With this update, target-namespace resolution respects the PipelineRun template annotation for explicit /test and /cancel GitOps commands. As a result, PipelineRuns are created in the correct namespace.

Branch and tag references parsed correctly in gitops comments

Before this update, gitops comment parsing could not distinguish between branch and tag references. As a consequence, branch-targeted commands could be incorrectly treated as tag references. With this update, the tag: prefix is used to correctly identify tag references. As a result, gitops comments target the correct ref type.

Watcher works correctly on clusters with restricted RBAC

Before this update, the watcher attempted pipelineruns/status updates which required permissions not granted on all clusters. As a consequence, forbidden errors occurred on clusters where the watcher service account lacks pipelineruns/status update permissions. With this update, the generated status sync is disabled for the watcher. As a result, the watcher works correctly on clusters with restricted RBAC.

Controller follows principle of least privilege

Before this update, the controller ServiceAccount had cluster-wide secrets/delete permission that was never used. As a consequence, the controller had broader permissions than necessary. With this update, the unused permission is removed. As a result, the controller follows the principle of least privilege.

Tekton Chains

Duplicate attestation and signature layers eliminated when same image reported multiple times

Before this update, when a task emitted multiple type-hint results such as IMAGE_URL/IMAGE_DIGEST, IMAGES, and ARTIFACT_OUTPUTS that all resolved to the same image digest, Tekton Chains produced duplicate attestation (.att) and signature (.sig) layers in the OCI registry. As a consequence, this created redundant attestation layers with identical payloads, wasted registry storage, and caused unnecessary KMS signing operations. With this update, Tekton Chains deduplicates by digest at both the extraction level and the storage level. As a result, exactly one attestation layer and one signature layer are created per unique image digest.

This content is not included.SRVKP-11363

Duplicate OCI layers for same digest type hints

Before this update, when multiple results with different type hints pointed to the same image digest, Tekton Chains could create duplicate .att and .sig Open Container Initiative (OCI) layers. As a consequence, this resulted in redundant storage and unnecessary signing operations. With this update, Tekton Chains deduplicates OCI layers based on the actual image digest. As a result, only one set of attestation and signature layers is created per unique digest.

OCI artifact signing in ARTIFACT_OUTPUTS

Before this update, when OCI artifacts were specified in ARTIFACT_OUTPUTS results, Tekton Chains did not sign them correctly. As a consequence, artifacts specified this way could be missed during the signing process. With this update, Tekton Chains correctly handles and signs OCI artifacts referenced in ARTIFACT_OUTPUTS results. As a result, all OCI artifacts are properly signed regardless of how they are specified in task results.

Docdb storage logic updated

Before this update, the Docdb storage backend had inefficient query logic for retrieving attestation data. As a consequence, this could impact performance when storing or retrieving attestations at scale. With this update, the Docdb storage logic is optimized for better performance. As a result, attestation storage and retrieval operations are more efficient.

Pipelines as Code

The pipelinerun_status field in the Repository CR is deprecated

The pipelinerun_status field in the Repository custom resource (CR), which tracks pipeline run status, was deprecated in OpenShift Pipelines 1.22 and will be removed in a future release. This field is not scalable and has caused issues. Migrate away from this field to avoid disruption when it is removed.

This content is not included.SRVKP-11931

Tekton Hub task resolution is deprecated

Tekton Hub catalog integration in Pipelines as Code is deprecated and will be removed in a future release. When you use Hub-based remote task or pipeline references, Pipelines as Code emits deprecation warnings in logs and documentation. Migrate to Artifact Hub or use remote URL-based or Git-based task references instead. For example, instead of referencing tasks through a Tekton Hub instance, fetch them directly from a Git repository URL or from Artifact Hub. Tekton Hub support will be removed in a future release of OpenShift Pipelines.

This content is not included.SRVKP-12187

CLI

Tekton Hub support in the tkn hub CLI is deprecated

Tekton Hub support in the tkn hub CLI is deprecated in favor of Artifact Hub. The following commands currently only work with Tekton Hub and might support Artifact Hub in a future release:

• check-upgrade
• downgrade
• get
• info
• reinstall
• search

• upgrade

  When using the --type tekton flag, a deprecation warning is displayed. You can migrate to Artifact Hub by using the --type artifact flag with the install command. For example:

  $ tkn hub install task foo --type artifact --from tekton-catalog-tasks

  Copy code to clipboard

  Artifact Hub at Content from artifacthub.io is not included.https://artifacthub.io will become the only supported hub in future releases.

  This content is not included.SRVKP-11950