#Release Notes

#Alauda DevOps (Next-Gen) - 4.3

#Compatibility and Support Matrix

The table below shows the version matrix of the Operators included in Alauda DevOps v4.3.

#New and Optimized Features

#Alauda DevOps Pipelines

• This update upgrades the catalog versions of existing Tasks and Pipeline templates, and introduces several new Tasks. In the updated versions, default tool images are pinned to fixed tags and some deprecated parameters are removed. Legacy versions are still available, but users are strongly recommended to migrate to the new versions as early as possible. For detailed behavior changes, see the README of each Task and Pipeline template.

  Task update summary:

  Task	Change Type	Version Path
  Helm Upgrade	New	-
  Golang	New	-
  Node.js	New	-
  Dotnet	New	-
  Workload Apply	New	-
  Send Mail	New	-
  Buildah	Upgraded	v0.9 -> v0.10
  Helm Chart Build Push	Upgraded	v0.1 -> v0.2
  Cosign	Upgraded	v0.1 -> v0.2
  Git CLI	Upgraded	v0.4 -> v0.5
  Git Clone	Upgraded	v0.9 -> v0.10
  Pytest	Upgraded	v0.2 -> v0.3
  Python	Upgraded	v0.1 -> v0.2
  Syft	Upgraded	v0.1 -> v0.2
  Trivy Scanner	Upgraded	v0.4 -> v0.5
  Maven	Upgraded	v0.5 -> v0.6
  SonarQube Scanner	Upgraded	v0.5 -> v0.6

  Pipeline template update summary:

  Pipeline Template	Change Type	Version Path
  Java Image Build Scan Deploy	Upgraded	v0.1 -> v0.2
  Python Image Build Scan Deploy	Upgraded	v0.1 -> v0.2

• More detailed release notes for different versions can be found in the Alauda DevOps Pipelines documentation center.

#Alauda DevOps Connectors

• This update expands tool integration coverage and adds finer-grained controls for browsing Connector data and using Connector proxy access.
• New Connector implementations are available for GitHub, JFrog Artifactory, and Nexus Repository.
• Permission controls are enhanced with optional connectors/apis and connectors/proxy checks, approval-gated proxy access through AccessPolicy and AccessRequest, and ACP platform roles for approval resources.
• Administration is improved with declarative feature flags in ConnectorsCore.spec.featureFlags, custom CA certificate support, Harbor CLI configuration, automatic Harbor Connector creation, and clearer CSI denial errors.
• More detailed release notes can be found in the Alauda DevOps Connectors documentation center.

#DevOps Toolchain

This update enhances the overall security and stability of the toolchain, which includes the following tools:

• Alauda Build of Gitlab
• Alauda Build of Harbor
• Alauda Build of Nexus
• Alauda Build of SonarQube

#Breaking Changes

• No breaking changes in this release.

#Deprecation Notices

• Starting from Connectors v1.10.0, ca.cert is deprecated in Connectors CSI built-in configurations. Use ca.crt instead.

#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.
• - 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.
• 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, 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, 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, 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, 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.
• Before this update, when users configured an HTTPS Nexus Maven repository with a custom CA certificate in Connector, the Maven authentication check did not use the Connector's CA certificate and could fail certificate validation. With this update, Maven authentication checks use the CA certificate configured on the Connector, so users can complete authentication for HTTPS Nexus Maven repositories normally.
• Before this update, when Connector accessed GitLab through the forward proxy, requests could carry X-Forwarded and related headers injected by an ALB or gateway. GitLab could return 403 even when the credentials were valid, causing page access or data retrieval to fail. With this update, Connector removes those gateway forwarding headers before forwarding requests, so GitLab access and data retrieval work normally when the credentials are valid.

#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.
• - 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.
• 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.