#发版日志

#兼容性和支持矩阵

下表展示了 Alauda DevOps Pipelines operator 与 ACP 各版本之间的兼容性和支持矩阵。

下表展示了 Alauda DevOps Pipelines 与 Alauda DevOps Connectors 之间的推荐版本映射。

#Channel 映射

有关 Channel 行为和升级目标的详细信息，请参阅 Upgrade Path 和 Lifecycle Policy。

#v4.10.1

#新增和优化的功能

修复了一个问题：由于镜像使用 x86_64_v3 指令构建，maven 和 sonarqube-scanner Tasks 无法在仅支持 x86_64_v2 或更低 CPU 指令集的节点上运行。

#破坏性变更

本次发版没有破坏性变更。

#已修复的问题

• 在此更新前，在 VMware 环境中运行 Java/Python 流水线时，Maven 和 SonarQube Scanner 任务可能会失败，因为 maven 与 sonarqube-scanner 镜像依赖 x86_64_v3 CPU 指令集，而仅支持 x86_64_v2 及以下指令集的节点无法满足该要求。通过此更新，这些镜像现已兼容上述环境，Maven/Sonar 任务以及 Java/Python 流水线可以正常运行。

#已知问题

• 在此更新之前，Connector 的 forward proxy 会对所有 HTTPS CONNECT 请求都走 MITM 拦截。因此，在 Tekton buildah task 的 Containerfile RUN 步骤里，访问非 connector 地址的 curl、apt-get、wget 等请求也会被路由到 MITM proxy，客户端必须额外信任 proxy CA 才能完成连接，给 buildah 构建等场景带来很大困扰。此次更新之后，forward proxy 会根据目标地址是否匹配 connector 来决定行为：匹配 connector 的请求继续走 MITM 并注入鉴权；不匹配 connector 的请求则走透明隧道，客户端直接看到上游真实证书，不再需要信任 proxy CA。这样既保留了 connector 地址的代理能力，也避免了非 connector 请求被错误地要求信任 MITM CA。
• 在此更新之前，Connector 的 forward proxy 会对所有 HTTPS CONNECT 请求都走 MITM 拦截。因此，在 Tekton buildah task 的 Containerfile RUN 步骤里，访问非 connector 地址的 curl、apt-get、wget 等请求也会被路由到 MITM proxy，客户端必须额外信任 proxy CA 才能完成连接，给 buildah 构建等场景带来很大困扰。此次更新之后，forward proxy 会根据目标地址是否匹配 connector 来决定行为：匹配 connector 的请求继续走 MITM 并注入鉴权；不匹配 connector 的请求则走透明隧道，客户端直接看到上游真实证书，不再需要信任 proxy CA。这样既保留了 connector 地址的代理能力，也避免了非 connector 请求被错误地要求信任 MITM CA。

#v4.10.0 (LTS)

#新增和优化的功能

Pipelines

• 本次更新升级了 catalog 中的 Task 和 Pipeline 版本。在这些版本中，工具镜像的默认值已固定为具体标签，同时移除了部分已弃用的参数字段。旧版本仍然可用，也可以继续使用，但建议用户尽早迁移到新版本。有关详细的变更说明，请参阅 Task 和 Pipeline 的 README。

  Task 版本升级

  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 版本升级

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

• 本次更新新增了 Helm Upgrade Task，用于支持从 OCI repository 拉取特定 chart 版本，并直接基于 Git 源目录部署或更新 Helm 应用。

• 本次更新新增了 Helm Chart Build Push Task，用于从目录打包 Helm charts，并使用 Helm 和 ORAS 推送到 OCI registry。

• 本次更新新增了 Golang Task，用于支持 Golang 构建、测试、lint、依赖缓存以及测试结果收集。

• 本次更新新增了 Node.js Task，用于支持 npm/yarn 构建、测试、lint 以及向 npm registry 发布。

• 本次更新新增了 .NET Task，用于支持命令执行、可选缓存以及 NuGet 配置。

• 本次更新新增了 Merge Image Task，用于将为不同 CPU 架构构建的镜像合并为单个镜像。

• 本次更新新增了 Workload Apply Task，用于支持 Kubernetes 工作负载更新、镜像更新、自定义 patch YAML，以及可配置的部署和回滚超时时间。

• 本次更新新增了 Send Mail Task，用于基于内置模板或自定义内容发送邮件通知。了解更多。

• 本次更新中，当重新运行 PipelineRun 时，系统会优先基于原始 PipelineRun 名称或其命名规则生成新名称。

• 本次更新中，图形化 pipeline 编辑支持卡片级错误提示，并在提交前进行阻断式校验。

Triggers

• 本次更新中，UI 中的 Trigger 编排支持 TriggerBinding 和 ClusterTriggerBinding 预览，帮助用户在引用之前查看可用参数。

#破坏性变更

本次发版没有破坏性变更。

#已修复的问题

• 在此更新之前， 当用户在 Hub 界面浏览或选择任务时，由于版本号是基于简单的文本比较或不兼容的数据库函数进行排序的，系统有时无法正确识别并显示“最新（latest）”版本。通过此次更新， Hub 严格遵循语义化版本（semver）标准来识别最新版本，确保用户在任务选择界面中始终能看到并选择任务的最新版本。
• 在此更新之前，在流水线中新增 integration（OCI 或 Harbor 类型）并选择 connector 后，点击 projects、repo 等参数输入框时未能正确调用 connector API，导致无法获取工具信息；通过此次更新，系统能够正常调用 connector API，获取工具信息并填充到输入框的可选项中。
• 在此更新之前，在创建流水线并通过 integration 挂载 connector 设置参数（如使用 Harbor integration 配置构建任务）后触发流水线时会失败，因为生成的 PipelineRun 中 workspace 配置不完整，通过 integration 设置的 workspace 未生效；通过此次更新，系统能够正确传递并挂载 integration 定义的 workspace，确保 PipelineRun 的 workspace 配置完整并可成功运行。
• 在此更新之前，Tekton 流水线运行时偶尔会因 resolver 获取远程 Pipeline 定义失败而以 reason: CouldntGetPipeline 结束，此类本可通过重试恢复的瞬时错误未触发自动重试，影响了流水线的可用性；通过此次更新，针对该错误类型补充了重试逻辑，受影响的流水线运行会自动重试并从此类瞬时错误中恢复。
• 在此更新之前，重新运行以内联形式（未引用 Pipeline）创建的 PipelineRun 时会弹出选择 Pipeline 的窗口并导致失败；通过此次更新，系统能够正确复用原始内联定义，从而支持直接重试并成功运行 PipelineRun。

#已知问题

• - 影响范围：节点只具备 x86_64_v2 及以下的 CPU 指令集时，无法使用 maven 与 sonarqube-scanner 镜像无法运行。
  - 问题原因：maven 与 sonarqube-scanner 镜像依赖 x86_64_v3 的 CPU 指令集。
  - 临时规避方法：使用单独提供的 workaround 镜像。
• - 影响范围：当 GitLab 访问入口为 HTTP/HTTPS 且端口非 80/443（例如 http://HOST:8081、https://HOST:8443）时，gitlab-mr-create Task 在 step-create-mr 步骤立即报 Error parsing --hostname: invalid hostname，无法创建 Merge Request；GitLab 使用 80/443 标准端口的部署不受影响。
  - 问题原因：Task 从 gitlabURL / projectPath 提取主机名时未剥离端口，将 HOST:PORT 直接作为 --hostname 传给 glab CLI，被 glab 在参数校验阶段直接拒绝；受影响版本的 glab_api 函数无条件带上 --hostname，切换 Connector 代理模式也无法绕过。
  - 临时规避方法：在 GitLab 前置一层 Ingress / nginx / HAProxy 监听 80 或 443 转发到真实端口，流水线里的 gitlabURL（或 projectPath）改成不带端口的入口地址即可；不需要调整 Task 版本、Secret 或 workspace 绑定。