#Release Notes

#Alauda DevOps (Next-Gen) - 4.1

#Compatibility and Support Matrix

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

#New and Optimized Features

#Alauda DevOps Pipelines

• Task Functionality Enhancement: New task types added, including kubectl, git, Python, and Pytest; standardized pipeline templates for Java, Helm and Python provided.
• Allow registration of custom Pipeline or Task in the Hub.
• Security Capabilities Upgrade: Integrated syft, cosign, and trivy tasks to enable image SBOM generation, signature verification, and vulnerability scanning.
• Configuration Enhancement: Supports pipeline trigger templates; EventListener now supports custom securityContext and imagePullSecrets configurations.
• User Experience Optimization: End-to-end experience optimization for pipeline orchestration.
• Tekton Community Upstream Issues Optimized.
• More detailed release notes for different versions can be found in the Alauda DevOps Pipelines documentation center.

#Alauda DevOps Connectors

• Supports using the OCI Connector when pulling images in Kubernetes.
• Adds a new Kubernetes Connector to integrate with Kubernetes clusters and use it in workloads/pipelines.
• Support integration with Maven and PyPI Registries by using Maven Connector and PyPI Connector.
• More detailed release notes for different versions 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:

• Alauda Build of Gitlab

• Alauda Build of Harbor

• Alauda Build of SonarQube

• Alauda Build of Nexus

#Breaking Changes

• Support for the ClusterTask object has been removed in this version of Alauda DevOps Pipeline.
• The OCI ConnectorClass resolver-type format has changed in Alauda DevOps Connectors, which may affect scenarios using the OCI connector.
• In Alauda DevOps Connectors, after upgrading to v1.1.0, connectors created in v1.0.8 may encounter errors.

#Fixed Issues

• Before this update, Pipeline runs with resolver Tasks would intermittently fail when webhook validation requests to tekton-pipelines-webhook service timed out during Task retrieval, resulting in pipeline failure without automatic retry. With this update, the system now properly handles retryable errors during resolver Task validation and implements retry logic to ensure reliable pipeline execution despite temporary network connectivity issues.
• Before this update, when users configured the tekton-hub-api-ssh-crds Secret for Tekton Hub to clone private repositories using SSH keys, the configuration was not properly applied and code repositories could not be cloned successfully even after restarting the pods. With this update, the tekton-hub-api-ssh-crds Secret configuration is correctly processed and applied, allowing Tekton Hub to successfully clone code from private repositories using SSH authentication.
• Before this update, Pipeline runs with resolver Tasks would intermittently fail when webhook validation requests to tekton-pipelines-webhook service timed out during Task retrieval, resulting in pipeline failure without automatic retry. With this update, the system now properly handles retryable errors during resolver Task validation and implements retry logic to ensure reliable pipeline execution despite temporary network connectivity issues.
• Before this update, if the project-ns-prefix feature flag was enabled in ACP, mounting a project-level Connector in a Namespace Pod under an ACP project in the business cluster would result in a permission error. After this update, the issue has been fixed — with the project-ns-prefix feature flag enabled in ACP, a Namespace Pod under an ACP project in the business cluster can now successfully mount a project-level Connector.
• Before this update, when users created instances of different tools (for example, GitLab and Harbor) with the same name, the later instance could be created but failed during deployment. With this update, the operator blocks the creation of duplicate names by returning an error, prompting users to change the release name.
• Before this update, when users created instances of different tools (for example, GitLab and Harbor) with the same name, the later instance could be created but failed during deployment. With this update, the operator blocks the creation of duplicate names by returning an error, prompting users to change the release name.
• Before this update, when deploying GitLab in high availability mode, the praefect component did not have default resource requests and limits configured, which could lead to resource contention or unpredictable scheduling behavior. With this update, the praefect component includes default resource settings with requests of 500m CPU and 500Mi memory, and limits of 2 CPU and 2Gi memory.
• Before this update, the operator continuously reconciled GitLab instances because of the HPA resource, which resulted in high CPU usage. With this update, the operator reconciles GitLab instances normally, reducing CPU consumption.
• Before this update, Pipeline runs with resolver Tasks would intermittently fail when webhook validation requests to tekton-pipelines-webhook service timed out during Task retrieval, resulting in pipeline failure without automatic retry. With this update, the system now properly handles retryable errors during resolver Task validation and implements retry logic to ensure reliable pipeline execution despite temporary network connectivity issues.
• Before this update, when tektoncd-operator deployed the Tekton Results component, if the external PostgreSQL credentials contained special characters such as "/", the deployment would fail. With this update, tektoncd-operator can successfully deploy the Tekton Results component even when the PostgreSQL credentials contain special characters like "/".
• Before this update, when you removed ConfigMap keys from the execution parameters in Alauda Pipeline UI, the removed keys were still included in the actual pipeline execution, causing inconsistency between the UI display and the actual pipeline behavior. With this update, the removal of ConfigMap keys in the UI is now correctly applied to the actual pipeline execution, ensuring consistency between the interface and runtime behavior.
• Before this update, after deploying the Connectors component, the component status appeared normal. However, when using the connectors-csi driver in a Pod, there were occasional errors indicating:
  "driver name connectors-csi not found in list of registered csi drivers", which caused the Pod to fail to start. With this update, the issue has been resolved. Once the deployment is complete and the component is in a healthy state, Pods can use the connectors-csi driver normally without encountering this intermittent error.
• Before this update, if the Connectors component was deployed in a namespace other than connectors-system, the `AuthReady` condition of any created OCI Connector would remain in a failed state. With this update, the issue has been resolved. The `AuthReady` condition of an OCI Connector is no longer affected by the namespace in which the Connectors component is deployed and can now accurately reflect the validity of the provided secret.
• Before this update, when deploying Connectors components on Kubernetes versions before 1.31, a bug in Kubernetes Server-side apply (https://github.com/kubernetes/kubernetes/issues/124605) would continuously update resource `resourceVersion`, potentially causing cluster stability issues. With this update, the connectors-operator now bypasses this issue by preventing reconciliation triggers when only `resourceVersion` changes occur on Kubernetes versions before 1.31.
• Before this update, when executing Tekton Pipeline workflows, users occasionally encountered random test case failures due to Out Of Memory (OOM) errors in init containers, which terminated with exit code 137 and caused pipeline execution failures. With this update, init container memory allocation has been optimized to prevent OOM errors, ensuring stable and reliable pipeline execution during frequent e2e testing scenarios.
• Before this update, when users configured the tekton-hub-api-ssh-crds Secret for Tekton Hub to clone private repositories using SSH keys, the configuration was not properly applied and code repositories could not be cloned successfully even after restarting the pods. With this update, the tekton-hub-api-ssh-crds Secret configuration is correctly processed and applied, allowing Tekton Hub to successfully clone code from private repositories using SSH authentication.
• Before this update, after deploying the Tektoncd Operator, the clustertriggerbinding resource required by trigger was not imported, resulting in inconvenience when using the trigger function. With this update, the resource will be automatically imported, making the trigger function easier to use.
• Before this update, Tekton Results components (tekton-results-api, tekton-results-retention-policy-agent, tekton-results-postgres) were storing secrets as environment variables, which violated the Kubernetes STIG security baseline requirement V-242415 that prohibits storing secrets as environment variables. With this update, these components no longer mount secrets through environment variables, ensuring compliance with Kubernetes security standards.
• Before this update, if there was an update in the Hub component of the Tektoncd Operator, manual intervention was required to trigger the upgrade. With this update, the system will automatically detect updates to the Hub component and trigger the upgrade automatically.
• Before this update, the tekton-hub-api component was generating zombie processes every 30 minutes when performing git clone operations, which could potentially cause node failures due to abnormal process behavior. With this update, the zombie process issue has been resolved through updates to the tektoncd-operator, and the system now operates without generating zombie processes during git operations.
• Before this update, the tekton-results-retention-policy-agent container in the Tekton Results retention policy agent component did not have CPU or memory limits configured, which posed a security vulnerability as containers could potentially consume unlimited resources. With this update, proper CPU and memory limits have been added to the retention-policy-agent container, ensuring resource usage is properly constrained and the security vulnerability is resolved.
• Before this update, the tekton-results-api container in the Tekton Results component did not have CPU or memory limits configured, which could lead to resource exhaustion and security vulnerabilities. With this update, proper CPU and memory limits have been added to the tekton-results-api container to ensure resource constraints and improve security posture.
• Before this update, when Tekton Chains was enabled and the default-pod-template configuration was modified after PipelineRun and TaskRun resources had completed, these resources could not be deleted due to a conflict between the default webhook (which attempted to update pod templates) and the validation webhook (which prevented spec modifications on completed resources). With this update, the default webhook no longer attempts to modify pod templates for completed PipelineRun and TaskRun resources, allowing them to be successfully deleted.
• Before this update, the tekton-results-watcher container in the tekton-results-watcher component did not have CPU or memory limits configured, which could lead to resource exhaustion and security vulnerabilities in Kubernetes environments. With this update, the tekton-results-watcher container now has proper CPU and memory limits configured, ensuring better resource management and security compliance.

#Known Issues

• If Pipelines with resolver Tasks encounter webhook validation timeouts during Task retrieval, the pipeline may fail intermittently without automatic retry. To resolve this issue, manually restart the failed pipeline run as the system does not currently implement retry logic for retryable webhook validation errors.