Примечания к выпуску
Примечания к выпуску включают агрегированное содержимое для нескольких версий каждого Operator в матрице совместимости Alauda DevOps v4.3. Более подробные примечания к выпуску для каждого Operator можно дополнительно посмотреть в соответствующем центре документации Operator.
Содержание
Alauda DevOps (Next-Gen) - 4.3Матрица совместимости и поддержкиНовые и оптимизированные возможностиAlauda DevOps PipelinesAlauda DevOps ConnectorsDevOps ToolchainИзменения, нарушающие совместимостьУведомления об устареванииИсправленные проблемыИзвестные проблемыAlauda DevOps (Next-Gen) - 4.3
Матрица совместимости и поддержки
Таблица ниже показывает матрицу версий Operators, включенных в Alauda DevOps v4.3.
Новые и оптимизированные возможности
Alauda DevOps Pipelines
-
В этом обновлении повышены версии каталога существующих шаблонов
TasksиPipeline, а также добавлено несколько новыхTasks. В обновленных версиях образы инструментов по умолчанию закреплены за фиксированными тегами, а некоторые устаревшие параметры удалены. Наследуемые версии по-прежнему доступны, однако пользователям настоятельно рекомендуется как можно раньше перейти на новые версии. Подробные изменения поведения см. в README каждого шаблона Task и Pipeline.Сводка обновлений Task:
Сводка обновлений шаблонов Pipeline:
-
Более подробные примечания к выпуску для разных версий можно найти в центре документации Alauda DevOps Pipelines.
Alauda DevOps Connectors
- В этом обновлении расширено покрытие интеграции инструментов и добавлены более детализированные элементы управления для просмотра данных Connector и использования прокси-доступа Connector.
- Доступны новые реализации Connector для
GitHub,JFrog ArtifactoryиNexus Repository. - Управление правами расширено за счет необязательных проверок
connectors/apisиconnectors/proxy, прокси-доступа с утверждением черезAccessPolicyиAccessRequest, а также ролей платформы ACP для ресурсов утверждения. - Администрирование улучшено за счет декларативных флагов функций в
ConnectorsCore.spec.featureFlags, поддержки пользовательских сертификатов CA, конфигурации Harbor CLI, автоматического создания Connector для Harbor и более понятных ошибок отказа CSI. - Более подробные примечания к выпуску можно найти в центре документации Alauda DevOps Connectors.
DevOps Toolchain
Это обновление повышает общую безопасность и стабильность toolchain, который включает следующие инструменты:
Изменения, нарушающие совместимость
- В этом выпуске отсутствуют изменения, нарушающие совместимость.
Уведомления об устаревании
- Начиная с
Connectors v1.10.0,ca.certсчитается устаревшим в встроенных конфигурацияхConnectors CSI. Вместо него используйтеca.crt.
Исправленные проблемы
- 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, 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.
Известные проблемы
- - 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.