#发版日志

#兼容性和支持矩阵

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

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

#Channel mapping

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

#v4.10.2

#新功能和优化

Tekton Hub

• 新安装默认不再部署集群内的 Tekton Hub；Hub 能力通过 ArtifactHub shim 提供。升级自之前已部署 Tekton Hub 的版本时，现有的 Tekton Hub 组件及其 catalog artifacts 将被保留并继续可用，因此现有的 Task 和 Pipeline 引用仍可正常解析。全新安装和升级路径均支持 air-gapped 环境。升级过程中，operator 会记录你环境中已在运行的 catalog image 并进行固定，同时保留现有的 catalog ConfigMap，避免被 garbage-collected。
• 新增 operator 级环境变量 AUTOINSTALL_TEKTONHUB（设置在 operator Deployment 上），用于控制 Tekton Hub 管理，取值有三个：preserve（默认——保留现有 Hub，且在全新安装时不部署 Hub）、true（显式部署并保留 Hub，用于 all profile）、false（显式移除任何现有 Hub——具有破坏性，仅在明确选择加入时使用）。任何未设置或无法识别的值都将视为 preserve。

#破坏性变更

本次发版没有破坏性变更。全新安装默认不包含集群内 Tekton Hub（与 v4.10.0 / v4.10.1 保持一致）；升级现在会保留现有的 Hub 和 catalog，而不是将其移除。

#已修复问题

• 在此更新之前，在流水线运行记录数据量较大的环境中，打开流水线详情的运行记录列表、打开单次运行的详情、以及查看某次运行的子记录都非常缓慢，等待时间可达一分钟以上，页面几乎无法使用。此次更新之后，Tekton Results 会在组件安装或升级时自动补齐运行记录所需的数据库索引，上述页面的响应时间由一分钟以上降至数秒以内，无需人工登录数据库手工创建索引。
• 在此更新之前，当 GitLab connector 以代理模式运行时，使用 gitlab-mr-create 任务创建合并请求会失败，报错提示 GITLAB_HOST 与仓库已配置的 git remote 不一致，导致合并请求无法创建。此次更新之后，已修复该问题，代理模式下该任务会通过 GitLab API 创建合并请求，可以正常创建成功。
• 在此更新之前，当 GitLab connector 以代理模式运行时，通过 gitlab-cli 任务执行 glab mr note、glab mr merge 等命令会失败，报错提示 GITLAB_HOST 与仓库已配置的 git remote 不一致，导致合并请求评论贴不上、自动合并也不生效。此次更新之后，已修复该问题，代理模式下这些命令会通过 GitLab API 执行，合并请求评论与自动合并可以正常生效。
• 在此更新之前，在 TektonConfig 的 Results 配置中设置 db_secret_name 后，Tekton Results API 组件的容器环境变量中会暴露该 Secret 中的凭据信息，不符合安全规范。此次更新之后，已修复该问题，配置 db_secret_name 后组件的环境变量中不会暴露凭据信息。
• 在此更新之前，在流水线页面打开过一次执行弹窗后，如果在别处新增了 Connector，不刷新流水线页面再次打开执行弹窗时，Connector 下拉框仍是旧数据，新增的 Connector 不会出现在列表中。此次更新之后，已修复该问题，每次打开执行弹窗都会重新获取最新的 Connector 列表，新增的 Connector 可以直接选择。
• - 影响范围：当 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 绑定。

#已知问题

此次发版无相关问题。

#v4.10.1

#新功能和优化

修复了由于使用 x86_64_v3 指令构建的 images 导致 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 的版本。在这些版本中，工具 image 的默认值已固定为具体 tag，同时移除了一些已弃用的参数字段。旧版本仍然可用并可继续使用，但建议用户尽早迁移到新版本。有关详细变更说明，请参见 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 source directory 部署或更新 Helm applications。

• 本次更新新增 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 架构构建的 images 合并为单个 image。

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

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

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

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

Triggers

• 本次更新中，UI 里的 Trigger orchestration 支持 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 绑定。