#发版日志

#兼容性和支持矩阵

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

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

#Channel 映射

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

#v4.14.0

#新增和优化的功能

Operator

• 本次更新将整个 Tekton 栈升级到新的基线：Tekton Pipelines v1.12、Triggers v0.36、Chains v0.27、Results v0.19、Pipelines as Code v0.48、Manual Approval Gate v0.9、Pruner v0.4 以及 tkn CLI v0.45。完整映射请参见 兼容性和支持矩阵。

Triggers

• 本次更新后，EventListener 导出规则除了现有的 Ingress 模式外，还可以通过将 type 设置为 HTTPRoute，经由 Gateway API HTTPRoute 暴露。这使得自动 webhook 暴露可以在不提供 IngressClass 且通过 Gateway 实现（例如 Envoy Gateway）转发外部流量的集群上正常工作。空的 type 仍然默认使用 Ingress，因此现有规则不受影响。详情请参见 Gateway API (HTTPRoute) mode。
• 本次更新后，由 ScheduledTrigger 注入的 $(context.date) 和 $(context.datetime) 占位符所使用的时区已被定义并记录：相同的有效时区会用于计算 cron schedule 并渲染占位符，解析顺序依次为 spec.timeZone、controller 的进程时区，最后是默认的 UTC。此前该值取决于 controller 镜像中恰好内置的本地时区，因此相同的 ScheduledTrigger 在不同集群上会产生不同的偏移量。详情请参见 Time Zone Resolution for Context Parameters。

Pipelines as Code

• 本次更新后，Pipelines as Code 通过 Kubernetes 上的 TektonConfig 进行配置。在默认的 spec.profile: all 下，operator 会根据 TektonConfig 派生 OpenShiftPipelinesAsCode CR 并保持同步，因此只需要编辑 TektonConfig。详情请参见 Manage PAC Component。
• 本次更新后，PAC 通过集群内的 artifacthub-shim 服务解析 catalog 资源。管理员配置的 hub URL 会被保留，其他 PAC controller 也会覆盖在内，包括升级后声明的 controller。

Catalog

• 本次更新后，旧版 TektonHub 自定义 catalog 配置会在移除 Tekton Hub 运行时之前迁移到 ArtifactHub Shim。operator 会读取 TektonHub.spec.catalogs[] 以及旧的 tekton-hub-api ConfigMap 中的 CATALOGS 数据，然后创建一个名为 artifacthub-shim-legacy-tekton-hub-catalogs 的 ArtifactHub Shim repository ConfigMap。
• 已迁移的 catalog 条目会分别生成 Tasks 的 <catalog>、Pipelines 的 <catalog>-pipelines 以及 StepActions 的 <catalog>-stepactions。生成的条目会使用 optional: true；Pipeline 和 StepAction 条目还会使用 legacyCatalogAliases，以便旧的 resolver 引用仍可继续使用原始 catalog 名称。
• 如果旧 Hub 目标命名空间中存在旧版 Tekton Hub SSH credential Secret tekton-hub-api-ssh-crds，operator 会将其规范化到 ArtifactHub Shim 命名空间中，命名为 artifacthub-shim-legacy-tekton-hub-ssh-creds，并在已迁移的 SSH catalog repository 中引用它。规范化后的 Secret 包含 sshPrivateKey 和 known_hosts；如果缺少 known_hosts 或存在多个私钥候选项，catalog 条目仍会迁移，但不会包含 credentialRef。
• 本次更新后，Hub resolver 的默认后端变为集群内的 artifacthub-shim 服务，使用兼容 Artifact Hub 的 API。详情请参见 Resolvers。

Web Console

• 本次更新后，运行对话框可以为 PipelineRun 配置 computeResources——即 CPU 和 memory 的 request 与 limit——而无需手动编辑 YAML。保存为 TriggerTemplate 以及再次执行 PipelineRun 时，这些值都会被保留。
• 本次更新后，运行配置还覆盖了 timeout，并支持单位选择和校验，因此常见的 PipelineRun 执行设置不再需要切换到 YAML。
• 本次更新后，当 console 无法解析 PipelineRun 的 pipelineRef 时，重新运行 PipelineRun 会回退到原始 PipelineRun 中记录的运行配置。通过 console 无法完全解析的 resolver 引用 Pipeline 时，params、workspaces 和 taskRunTemplate 不再丢失或被重置。
• 本次更新后，pipeline 可以通过 Multi Connector 同时绑定不同类型的 Integration。
• 本次更新后，Hub catalog 请求会携带当前 Workspace namespace，并且 list、detail 和 manifest 缓存会按集群和 namespace 隔离。切换 Workspace 后，不会再显示或解析在目标 namespace 中不可见的 catalog 资源。
• 本次更新后，Task 和 Pipeline 列表使用轻量级分页 API，并按需加载 README 和 manifest 内容，从而缩短大型 catalog 的首屏渲染时间。
• 本次更新后，多个 UI 细节得到优化，包括动态表单编写（workspace 和 result 的多语言显示字段、字符串字段的代码编辑、Integration 表单模式兼容性，以及 Result 类型和对象属性渲染）、pipeline 拓扑布局、默认停留在 Details 选项卡的详情页、面包屑和浏览器标题、tag 触发的运行源导航，以及 Repository 详情页中的 cluster resolver PipelineRun。

#破坏性变更

• 从本次发版开始，内置的 Tekton Hub 运行时不再随版本提供。operator 不再包含 Tekton Hub manifests，并且在 v4.12.0 中引入的 AUTOINSTALL_TEKTONHUB 开关已被移除，因此升级后无法重新启用内置的 Tekton Hub。因此，兼容性矩阵中的 Hub 列从 4.14.x 开始为空。

  • catalog 的发布和消费由 ArtifactHub Shim 提供服务，它有自己的生命周期。自定义 catalog 配置会自动迁移——有关迁移会覆盖和不会覆盖的内容，请参见上面的 Catalog 和下面的 升级说明。
  • Tekton Hub 文档部分已随运行时一起移除。有关 catalog 编写和消费指南，请参见 ArtifactHub Shim Catalog。

• 从本次发版开始，在 Kubernetes 平台上，TektonConfig 负责管理 Pipelines as Code 的部署。直到 v4.12.x，Kubernetes 上的 TektonConfig 中都没有 PAC 区块，因此 PAC 一直通过直接编辑 OpenShiftPipelinesAsCode CR 进行配置。现在该 CR 会从 TektonConfig 派生：operator 会为其设置 owner reference，并在每次 reconcile 时覆盖 targetNamespace、config、settings、options 和 additionalPACControllers。排障时请读取它，但写入请使用 TektonConfig。请注意，PAC 只会在 spec.profile: all 时被 reconcile；在 basic 或 lite 下，operator 完全不会处理 PAC。详情请参见 Manage PAC Component。

#升级说明

Pipelines as Code

• 升级已配置独立 OpenShiftPipelinesAsCode CR 的 Kubernetes 集群时，会先将其 settings、additionalPACControllers，以及 TektonConfig 中没有对应字段的 Alauda 特定设置复制到 TektonConfig，然后再由 adoption 覆盖这些设置。TektonConfig 中已经存在的值绝不会被覆盖，独立 CR 也绝不会被删除。spec.config 在 TektonConfig 中没有按组件对应项；operator 会对其发出警告，而不是自行猜测。
• adoption 还会将 PAC 迁移到 TektonConfig 的目标命名空间。Git provider credential Secret pipelines-as-code-secret 会被复制，global Repository 会被移动到新命名空间，二者都会附加 operator.tekton.dev/copied-from-namespace 注解。它们都不会覆盖目标命名空间中已存在的对象，用户创建的 Repository 资源也不会受影响。
• 任何真正使用 Tekton Hub API 的 catalog 现在都必须显式声明 catalog-<n>-type: tektonhub。catalog 类型自动检测不再在 admission 路径中探测网络，因此不会在 air-gapped 集群上卡住。

Catalog

• 迁移会将资源写入从 TektonConfig.spec.pipeline.hub-resolver-config.artifact-hub-api 解析得到的 ArtifactHub Shim 命名空间；当该值不可用时，默认命名空间为 artifacthub-shim-system。
• 迁移不会获取 TektonHub.spec.api.hubConfigUrl，也不会克隆 Git repository。请确保在升级前，TektonHub.spec.catalogs[] 或集群内 tekton-hub-api ConfigMap 的 CATALOGS 数据中已存在自定义 catalog 定义。有关配置迁移后自定义 catalog 源的详细信息，请参见 Configure Custom Git Repositories。
• operator 会跳过与现有 ArtifactHub Shim repository 名称或同类 alias 冲突的生成条目。它还会保留未由此次迁移生成的同名 ConfigMap 或 Secret。

#已修复的问题

• 在此更新之前，当一个 Task 中有两个及以上 step 通过引用方式使用 StepAction、且存在既声明了默认值又被 TaskRun 赋值的 object 类型参数时，并发解析 StepAction 引用会触发 Go 运行时的 concurrent map writes 致命错误，导致 tekton-pipelines-controller 整个进程崩溃重启，崩溃副本上正在处理的 PipelineRun 和 TaskRun 协调随之中断；通过此次更新，该并发写入问题已修复，上述场景不再导致控制器崩溃。
• 在此更新之前，在执行记录数量较大的环境中，控制台的流水线相关页面加载缓慢甚至不可用——打开流水线详情的 PipelineRun 列表约需 76 秒、打开单个 PipelineRun 详情约需 55 秒、列出某次运行的子记录约需 99 秒，原因是 Tekton Results 的 records 表缺少控制台高频查询所需的索引，数据库只能逐行扫描并解压 JSONB 数据来过滤；通过此次更新，为 records 表补齐了这些查询所需的索引，并把索引创建纳入 API 启动时的自动迁移，组件新装或升级后索引自动就位、无需人工登录数据库执行 DDL，上述查询在实测环境中从数十秒回到亚秒级。
• 在此更新之前，在 GitLab 上从默认分支的当前 commit 创建新分支、且创建过程中不产生任何新 commit 时，push webhook 的 commits 数组为空，Pipelines as Code 会把该事件当作无效事件跳过并报 no commits attached to this push event，分支创建不会自动触发流水线，用户只能在目标 commit 上手动用 /test 评论触发；通过此次更新，即使 webhook 的 commits 为空，Pipelines as Code 也会使用 after 字段识别对应的 commit 并继续执行 Repository 与 PipelineRun 的匹配流程，这类分支创建事件可以正常触发流水线。GitHub 不受该问题影响。
• 在此更新之前，Manual Approval Gate 的审批组名校验不允许包含冒号，导致以 system:authenticated 等标准 Kubernetes 组作为审批组的多人审批无法通过校验，审批任务始终停留在 pending 状态、下游流水线一直等待至超时；通过此次更新，审批组名允许使用带冒号的标准 Kubernetes 组，基于组成员身份的多人审批可以正常完成。
• 在此更新之前，已完成的执行记录被 pruner 从 etcd 清理、或被用户主动删除后，流水线执行列表不会自动从 Tekton Results 加载这些归档记录，需要手动刷新才能重新看到，甚至出现按名称能搜到、列表里却没有的不一致，用户容易误以为执行记录已经丢失；通过此次更新，执行列表能正确读取 Results 中的归档数据，列表展示与按名称搜索的结果保持一致。
• 在此更新之前，已归档但历史状态仍为 Running 或 Pending 的 PipelineRun 和 TaskRun 在列表中继续以“运行中”和加载动画展示，首次遇到的用户容易误以为资源仍在继续执行；通过此次更新，这类记录在列表中以中性的“已归档”状态展示，状态提示中同样标明“已归档”并保留原有的 Reason 与 Message，PipelineRun 的任务状态统计中处于归档运行态的任务也计入中性状态段，用户可以直接区分已归档的记录与真正还在执行的记录。
• 在此更新之前，使用 image-mirror 流水线一次同步较多镜像（实测约 14 个及以上）时，任务结果中的镜像清单会超过 Tekton termination message 的 4096 字节上限，即使镜像已全部拷贝成功，PipelineRun 仍会以 “Termination message is above max allowed size 4096” 失败，用户只能手动把镜像拆成多条流水线同步；通过此次更新，skopeo-copy 新增 maxResultImages 参数限制写入结果的镜像条数，并通过 dst-images-count 如实回传镜像总数，一次同步较多镜像不再导致流水线失败。
• 在此更新之前，当 TriggerTemplate 中某个参数的默认值为空字符串、且 ScheduledTrigger 未显式传入该参数时，定时触发创建出的 PipelineRun 中会残留未解析的 $(tt.params.<name>) 占位符；通过此次更新，空字符串同样被视为有效默认值参与渲染，定时触发创建的 PipelineRun 不再出现未解析的参数占位符。
• 在此更新之前，流水线列表页中每条流水线的最近执行记录方块没有按执行时间排序，展示出来的并不总是真正最近的几次执行，与用户预期不符；通过此次更新，这些记录按创建时间倒序排列，方块展示的就是该流水线最近的几次执行。
• 在此更新之前，在流水线编辑页面切换 Task 时，如果前后两个 Task 引用的定义不同，上一个 Task 的参数会残留在表单中，出现与当前 Task 无关的参数；通过此次更新，切换 Task 时会清理这些已失效的参数，表单只保留当前 Task 定义所声明的参数；同时在表单自动回填数据、当前 Task 定义尚未加载完成的过程中会保留已填写的参数，避免误清用户输入。
• 在此更新之前，在流水线执行详情页的 Task Overview 中点击 “Go To SonarQube” 链接不会在新标签页打开，链接的 target 属性在页面渲染时被过滤掉；通过此次更新，该链接可以正常在新标签页打开。
• 在此更新之前，Tekton Results 的 watcher 在 TaskRun 和 PipelineRun 创建时就会写入记录并随资源变化持续更新，未完成的执行也会被归档，因此列表中会出现状态仍为“运行中”的归档记录，用户无法从状态上判断资源是否还在执行，同时 Results API 与数据库也承受了额外的写入压力；通过此次更新，提供了关闭未完成执行记录实时归档的配置指引：在 TektonConfig 中为 tekton-results-watcher 添加 --disable_storing_incomplete_runs=true 参数后，未达到终态的执行不再写入 Tekton Results，只有执行结束后才会归档，归档记录的状态与实际执行情况保持一致，Results API 与数据库的写入压力也随之下降。

#已知问题

此次发版无相关问题。