#发版日志

#Alauda DevOps (Next-Gen) - 4.3

#兼容性与支持矩阵

下表显示了 Alauda DevOps v4.3 中包含的 Operators 版本矩阵。

#新增和优化功能

#Alauda DevOps Pipelines

• 此次更新升级了现有 Tasks 和 Pipeline 模板的目录版本，并引入了若干新的 Tasks。在更新后的版本中，默认工具镜像已固定到特定 tag，并移除了一些已弃用参数。旧版本仍然可用，但强烈建议用户尽早迁移到新版本。有关详细行为变化，请参阅每个 Task 和 Pipeline 模板的 README。

  Task 更新摘要：

  Task	变更类型	版本路径
  Helm Upgrade	新增	-
  Golang	新增	-
  Node.js	新增	-
  Dotnet	新增	-
  Workload Apply	新增	-
  Send Mail	新增	-
  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
  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 Template	变更类型	版本路径
  Java Image Build Scan Deploy	升级	v0.1 -> v0.2
  Python Image Build Scan Deploy	升级	v0.1 -> v0.2

• 不同版本的更详细发版日志可在 Alauda DevOps Pipelines 文档中心查看。

#Alauda DevOps Connectors

• 此次更新扩展了工具集成覆盖范围，并为浏览 Connector 数据和使用 Connector 代理访问增加了更细粒度的控制。
• 新增了面向 GitHub、JFrog Artifactory 和 Nexus Repository 的 Connector 实现。
• 权限控制得到增强，新增可选的 connectors/apis 和 connectors/proxy 检查、通过 AccessPolicy 和 AccessRequest 进行审批门控的代理访问，以及用于审批资源的 ACP 平台角色。
• 管理功能得到改进，包括 ConnectorsCore.spec.featureFlags 中的声明式 feature flags、自定义 CA 证书支持、Harbor CLI 配置、自动创建 Harbor Connector，以及更清晰的 CSI 拒绝错误。
• 更详细的发版日志可在 Alauda DevOps Connectors 文档中心查看。

#DevOps 工具链

此次更新增强了工具链的整体安全性和稳定性，其中包括以下工具：

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

#破坏性变更

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

#弃用通知

• 从 Connectors v1.10.0 开始，ca.cert 在 Connectors CSI 内置配置中已弃用。请改用 ca.crt。

#已修复问题

• 在此更新前，在 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。
• - 影响范围：当 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 绑定。
• 在此更新之前，当 SonarQube 实例配置了 external PostgreSQL（spec.helmValues.jdbcOverwrite.enabled=true）时，若 main 容器因任意原因重启（如数据库未就绪、首次 schema migration 超时、OOM 等），实例会静默回落到内嵌 H2 数据库继续运行，实例状态显示 Running/Successful，但数据实际写入 PVC 内的 H2 文件，外接 PostgreSQL 始终为空库。此次更新之后，JDBC 配置具备幂等性，容器重启后实例始终连接外接 PostgreSQL，不再发生静默回落。
• 在此更新之前， 当用户在 Hub 界面浏览或选择任务时，由于版本号是基于简单的文本比较或不兼容的数据库函数进行排序的，系统有时无法正确识别并显示“最新（latest）”版本。通过此次更新， Hub 严格遵循语义化版本（semver）标准来识别最新版本，确保用户在任务选择界面中始终能看到并选择任务的最新版本。
• 在此更新之前，Tekton 流水线运行时偶尔会因 resolver 获取远程 Pipeline 定义失败而以 reason: CouldntGetPipeline 结束，此类本可通过重试恢复的瞬时错误未触发自动重试，影响了流水线的可用性；通过此次更新，针对该错误类型补充了重试逻辑，受影响的流水线运行会自动重试并从此类瞬时错误中恢复。
• 在此更新之前，在流水线中新增 integration（OCI 或 Harbor 类型）并选择 connector 后，点击 projects、repo 等参数输入框时未能正确调用 connector API，导致无法获取工具信息；通过此次更新，系统能够正常调用 connector API，获取工具信息并填充到输入框的可选项中。
• 在此更新之前，在创建流水线并通过 integration 挂载 connector 设置参数（如使用 Harbor integration 配置构建任务）后触发流水线时会失败，因为生成的 PipelineRun 中 workspace 配置不完整，通过 integration 设置的 workspace 未生效；通过此次更新，系统能够正确传递并挂载 integration 定义的 workspace，确保 PipelineRun 的 workspace 配置完整并可成功运行。
• 在此更新之前，重新运行以内联形式（未引用 Pipeline）创建的 PipelineRun 时会弹出选择 Pipeline 的窗口并导致失败；通过此次更新，系统能够正确复用原始内联定义，从而支持直接重试并成功运行 PipelineRun。
• 在此更新之前，当用户在 Connector 中配置使用自定义 CA 证书的 HTTPS Nexus Maven 仓库时，Maven 认证检查未使用该 Connector 的 CA 证书，可能因证书校验失败而无法通过认证。此次更新之后，Maven 认证检查会使用 Connector 配置的 CA 证书，用户可以正常完成 HTTPS Nexus Maven 仓库认证。
• 在此更新之前，当 Connector 通过正向代理访问 GitLab 时，请求中可能携带 ALB 或网关注入的 X-Forwarded 等转发 header，导致 GitLab 即使在凭据正确时也返回 403，页面访问或数据获取失败。此次更新之后，Connector 转发请求前会移除这些网关转发 header，凭据正确时可以正常访问 GitLab 并获取数据。

#已知问题

• 在此更新之前，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。
• - 影响范围：节点只具备 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 绑定。
• 在此更新之前，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。