#Release Notes

#Compatibility and support matrix

The following table shows the compatibility and support matrix between the Alauda DevOps Pipelines operator and ACP versions.

The following table shows the recommended version mapping between Alauda DevOps Pipelines and Alauda DevOps Connectors.

#Channel mapping

For details about channel behavior and upgrade targeting, see Upgrade Path and Lifecycle Policy.

#v4.10.2

#New and Optimized Features

Tekton Hub

• Fresh installations no longer deploy the in-cluster Tekton Hub by default; the Hub capability is provided through the ArtifactHub shim. When upgrading from an earlier release that had Tekton Hub deployed, the existing Tekton Hub component and its catalog artifacts are now preserved and remain usable, so existing Task and Pipeline references continue to resolve. Both the fresh-install and upgrade paths work in air-gapped environments. During an upgrade the operator records the catalog image already running in your environment and pins it, and it retains the existing catalog ConfigMaps so they are not garbage-collected.
• A new operator-level environment variable AUTOINSTALL_TEKTONHUB (set on the operator Deployment) controls Tekton Hub management with three values: preserve (default — keep an existing Hub, and do not deploy one on a fresh install), true (explicitly deploy and keep the Hub, for the all profile), and false (explicitly remove any existing Hub — destructive, opt-in only). Any unset or unrecognized value is treated as preserve.

#Breaking Changes

No breaking changes in this release. Fresh installations do not include the in-cluster Tekton Hub by default (unchanged from v4.10.0 / v4.10.1); upgrades now retain their existing Hub and catalog instead of removing it.

#Fixed Issues

• Before this update, in environments with a large number of pipeline run records, the pipeline pages in the console were nearly unusable: listing the runs of a pipeline, opening a single PipelineRun, and listing the child records of a run each took more than a minute. With this update, Tekton Results automatically creates the required database indexes when the component is installed or upgraded, so these pages respond within a few seconds instead of over a minute, and no manual database work is needed.
• Before this update, when the GitLab connector ran in proxy mode, the gitlab-mr-create task failed to open a merge request, reporting that GITLAB_HOST did not match any git remote configured for the repository, so the merge request could not be created. With this update, the task creates the merge request through the GitLab API in proxy mode, and merge request creation succeeds.
• Before this update, when the GitLab connector ran in proxy mode, commands such as glab mr note and glab mr merge executed through the gitlab-cli task failed, reporting that GITLAB_HOST did not match any git remote configured for the repository. As a result, merge request comments were not posted and auto-merge did not take effect. With this update, these commands run through the GitLab API in proxy mode, so merge request comments and auto-merge work as expected.
• Before this update, after setting db_secret_name in the Results section of TektonConfig, the credentials from that Secret were exposed in the environment variables of the Tekton Results API component, which did not meet security requirements. With this update, the issue has been fixed, and the credentials are not exposed in the component's environment variables when db_secret_name is configured.
• Before this update, once the pipeline run dialog had been opened, a connector added elsewhere was missing from the dropdown when the dialog was reopened without refreshing the pipeline page, and the old connector list was still shown. With this update, the run dialog reloads the connector list every time it is opened, so a newly added connector is immediately available for selection.
• - Impact Scope: When GitLab is exposed over HTTP/HTTPS on a non-standard port (e.g. http://HOST:8081, https://HOST:8443), the gitlab-mr-create Task fails immediately in step-create-mr with Error parsing --hostname: invalid hostname and cannot create the Merge Request; GitLab deployments on the standard 80/443 ports are not affected.
  - Root Cause: The Task extracts the hostname from gitlabURL / projectPath without stripping the port and passes HOST:PORT directly to glab --hostname, which glab rejects at argument validation. The affected Task version always passes --hostname unconditionally, so switching to Connector proxy mode does not work around it either.
  - Temporary Workaround: Place an Ingress / nginx / HAProxy in front of GitLab that listens on port 80 or 443 and forwards to the real backend port, then change gitlabURL (or projectPath) in the pipeline to the port-less entry point. No Task version upgrade, Secret, or workspace binding changes are required.

#Known Issues

No issues in this release.

#v4.10.1

#New and Optimized Features

Fixed an issue where the maven and sonarqube-scanner Tasks failed to run on nodes that only support x86_64_v2 or lower CPU instruction sets, caused by images built with x86_64_v3 instructions.

#Breaking Changes

No breaking changes in this release.

#Fixed Issues

• Before this update, Maven and SonarQube Scanner tasks in Java and Python pipelines could fail in VMware environments because the maven and sonarqube-scanner images required the x86_64_v3 CPU instruction set, which is not available on nodes that support only x86_64_v2 or lower. With this update, these images are now compatible with such environments, allowing Maven/Sonar tasks and Java/Python pipelines to run normally.

#Known Issues

• Before this update, the Connector forward proxy MITM-intercepted every HTTPS CONNECT request. As a result, in Tekton buildah task Containerfile RUN steps, requests to non-connector destinations such as curl, apt-get, and wget were also routed through the MITM proxy, forcing clients to trust the proxy CA even when the traffic did not need Connector interception. This caused major friction for buildah-based builds. With this update, the forward proxy chooses behavior based on whether the target matches a connector address: requests to connector addresses continue to use MITM with auth injection, while requests to non-connector addresses fall back to a transparent tunnel so the client sees the real upstream certificate and no proxy CA trust is required. This preserves proxy behavior for connector traffic while avoiding the incorrect CA requirement for unrelated HTTPS requests.
• Before this update, the Connector forward proxy MITM-intercepted every HTTPS CONNECT request. As a result, in Tekton buildah task Containerfile RUN steps, requests to non-connector destinations such as curl, apt-get, and wget were also routed through the MITM proxy, forcing clients to trust the proxy CA even when the traffic did not need Connector interception. This caused major friction for buildah-based builds. With this update, the forward proxy chooses behavior based on whether the target matches a connector address: requests to connector addresses continue to use MITM with auth injection, while requests to non-connector addresses fall back to a transparent tunnel so the client sees the real upstream certificate and no proxy CA trust is required. This preserves proxy behavior for connector traffic while avoiding the incorrect CA requirement for unrelated HTTPS requests.

#v4.10.0 (LTS)

#New and Optimized Features

Pipelines

• With this update, catalog Task and Pipeline versions are upgraded. In these versions, tool image defaults are pinned to fixed tags, and some deprecated parameter fields are removed. Previous versions remain available and can continue to be used, but users are recommended to migrate to the new versions as early as possible. For detailed change descriptions, refer to the Task and Pipeline READMEs.

  Task Version Upgrades

  Task	Version Upgrade Path
  Buildah	v0.9 -> v0.10
  Helm Chart Build Push	v0.1 -> v0.2
  Cosign	v0.1 -> v0.2
  Git CLI	v0.4 -> v0.5
  Git Clone	v0.9 -> v0.10
  Merge Image	new -> v0.2
  Pytest	v0.2 -> v0.3
  Python	v0.1 -> v0.2
  Syft	v0.1 -> v0.2
  Trivy Scanner	v0.4 -> v0.5
  Maven	v0.5 -> v0.6
  SonarQube Scanner	v0.5 -> v0.6

  Pipeline Version Upgrades

  Pipeline	Version Upgrade Path
  Java Image Build Scan Deploy	v0.1 -> v0.2
  Python Image Build Scan Deploy	v0.1 -> v0.2

• With this update, a new Helm Upgrade Task is added to support pulling a specific chart version from an OCI repository and deploying or updating Helm applications directly from a Git source directory.

• With this update, a new Helm Chart Build Push Task is added to package Helm charts from a directory and push them to an OCI registry by using Helm and ORAS.

• With this update, a new Golang Task is added to support Golang build, test, lint, dependency caching, and test result collection.

• With this update, a new Node.js Task is added to support npm/yarn build, test, lint, and npm registry publishing.

• With this update, a new .NET Task is added to support command execution, optional caching, and NuGet configuration.

• With this update, a new Merge Image Task is added to merge images built for different CPU architectures into a single image.

• With this update, a new Workload Apply Task is added to support Kubernetes workload updates, image updates, custom patch YAML, and configurable deployment and rollback timeouts.

• With this update, a new Send Mail Task is added to support email notifications based on built-in templates or custom content. Learn More.

• With this update, when rerunning a PipelineRun, the system prioritizes generating the new name based on the original PipelineRun name or its naming rule.

• With this update, graphical pipeline editing supports card-level error indication and blocking validation before submission.

Triggers

• With this update, Trigger orchestration in the UI supports TriggerBinding and ClusterTriggerBinding preview, helping users inspect available parameters before referencing them.

#Breaking Changes

No breaking changes in this release.

#Fixed Issues

• Before this update, transient network or infrastructure issues during the catalog synchronization process could cause the update task to fail and stop, preventing new tasks or updates from appearing in the Hub. With this update, a resilient retry and recovery mechanism has been implemented, ensuring that the Hub can automatically recover from temporary failures and keep the task catalog consistently up-to-date.
• Before this update, when adding an integration (OCI or Harbor type) in the pipeline and selecting a connector, the system failed to correctly invoke the connector API when interacting with fields such as projects or repositories, resulting in no available options being loaded; with this update, the connector API is properly called, enabling tool information to be retrieved and populated into the input fields as selectable options.
• Before this update, when creating a pipeline and using an integration to mount a connector for setting parameters (for example, using a Harbor integration for a buildah task), triggering the pipeline would fail because the generated PipelineRun did not include the complete workspace configuration and the workspace defined via the integration was missing; with this update, the system correctly propagates and mounts the integration-defined workspace, ensuring the PipelineRun is created with complete workspace content and can run successfully.
• Before this update, Tekton pipeline runs occasionally failed with the reason CouldntGetPipeline when the resolver was unable to fetch the remote Pipeline definition, and this transient error—which should have been recoverable—was not automatically retried, reducing pipeline reliability; with this update, retry logic is added for this error type, so affected pipeline runs are automatically retried and can recover from such transient resolver failures.
• Before this update, retrying a PipelineRun created in inline mode (without a Pipeline reference) would prompt users to select a Pipeline and result in failure; with this update, the system correctly reuses the original inline definition, allowing the PipelineRun to be retried directly and run successfully.

#Known Issues

• - Impact Scope: The maven and sonarqube-scanner images will fail to run on nodes that only support x86_64_v2 or lower CPU instruction sets.
  - Root Cause: The maven and sonarqube-scanner images require the x86_64_v3 instruction set.
  - Temporary Workaround: Use the separately provided workaround images.
• - Impact Scope: When GitLab is exposed over HTTP/HTTPS on a non-standard port (e.g. http://HOST:8081, https://HOST:8443), the gitlab-mr-create Task fails immediately in step-create-mr with Error parsing --hostname: invalid hostname and cannot create the Merge Request; GitLab deployments on the standard 80/443 ports are not affected.
  - Root Cause: The Task extracts the hostname from gitlabURL / projectPath without stripping the port and passes HOST:PORT directly to glab --hostname, which glab rejects at argument validation. The affected Task version always passes --hostname unconditionally, so switching to Connector proxy mode does not work around it either.
  - Temporary Workaround: Place an Ingress / nginx / HAProxy in front of GitLab that listens on port 80 or 443 and forwards to the real backend port, then change gitlabURL (or projectPath) in the pipeline to the port-less entry point. No Task version upgrade, Secret, or workspace binding changes are required.