rhdh-konflux-tasks

Konflux Tekton 任务更新

Konflux 任务标签升级后，确保构建继续正常运行：更新固定的 tag@sha256 摘要，按各任务的 MIGRATION.md 文档执行迁移，并 重新生成 PipelineRuns，使其与迁移后的模板匹配。

路由

加载 workflows/konflux-task-update.md。它会检测仓库布局，并 引导你前往相应的参考文档：

• references/konflux-plugin-catalog.md — rhdh-plugin-catalog， 标记文件为 .tekton/updatePLRs.sh（main / 2.1+）。在 1.9 和 1.10 流中，生成器 仍名为 .tekton/generatePipelineRunsForPlugins.sh（已弃用； 布局相同）。
• references/konflux-rhdh-midstream.md — RHDH midstream，变体 A （.tekton-templates/rhdh-pipeline.yaml）和变体 B（.tekton-templates/rhdh-hub.yaml，并使用共享的 build-pipeline-rhdh-*.yaml）。
• references/konflux-migration-urls.md — 根据任务名称和标签查找实时的 MIGRATION.md，因为大多数任务已离开 konflux-ci/build-definitions，其下的版本化路径现已返回 404。
• references/konflux-trusted-tasks.md — ECP / 已过期 / 不受信任的固定版本； 使用 scripts/check-trusted-tasks.sh 检查 data-acceptable-bundles。

完成摘要更新、迁移和受信任任务检查后，按名称调用 /rhdh-base-images，选择匹配的 GitHub main 或 release-* 分支（参见 konflux-task-update.md 第 5 步）。不要在此处运行该技能的脚本。

与插件 midstream 传播的边界

两个技能都会修改 .tekton，但原因不同。

• 此技能负责整个流的 Konflux 任务维护：更新摘要、迁移模板和共享流水线，以及为分支上的每个组件完整重新生成 PipelineRun。
• /rhdh-plugin-midstream-propagate 负责将单个插件工作区通过覆盖层推广到目录中，包括与之配套的、针对单个工作区的 PLR 标签精确修改——有意不进行完整重新生成。

如果请求是“此插件版本需要进入 midstream”，应使用 /rhdh-plugin-midstream-propagate。如果请求是“Konflux 任务已变更，流水线需要跟进”，则应使用此技能。切勿为了交付单个工作区的更新而完整重新生成；这会重写每个组件的 PLR。

与基础镜像的边界

/rhdh-base-images 负责 FROM 标签、rpms.lock.yaml、Node 头文件（.nvm/releases/node-v*-headers.tar.gz）、operator go.mod、plugin-catalog builder.Containerfile / .nvm/ / konflux.additional-tags，以及覆盖层 versions.json 中的 node。此技能不会重建该工作流，而是将 Konflux 流映射到 GitHub 分支选择器，指定检出项（用户提供的，或通过 /rhdh-context 获取的，包括目录和覆盖层），并调用 /rhdh-base-images。

Konflux 日志中的 could not find releases/node-v*-headers.tar.gz 属于该移交范围，而不是 Tekton 固定版本问题。不要在此技能中固定目录的 FROM 版本，也不要复制 .nvm/。

Konflux / 目录流	/rhdh-base-images -b
rhdh-1.9-rhel-9	release-1.9
rhdh-1.10-rhel-9	release-1.10
release-2.Y	release-2.Y
main (2.1+)	main
其他 rhdh-<ver>-rhel-<N>	若存在对应的 GitHub 分支，则为 release-<ver>

与 Mintmaker 的职责边界

Mintmaker 的 Tekton 管理器和此技能都会处理任务固定版本，但两者的工作不同。

• 每周维护不再运行 updateDigests.sh。Mintmaker 会自动合并 rhdh 和 rhdh-plugin-catalog 的相同标签摘要和补丁标签（konflux/digests/<branch>，每个分支一个 MR）。
• Mintmaker 会运行上游任务迁移脚本，因此次要或主要版本升级可能会重写 YAML（BUILD_ARGS_FILE → BUILD_ARGS_FILES、 CACHI2_ARTIFACT → PREFETCH_ARTIFACT）。这些 MR 保留在 konflux/migrations/<branch>，且不会自动合并。Mintmaker 不会运行 generatePipelineRuns.sh。
• 不要将迁移 MR 作为摘要更新的重复内容关闭。剩余的标签升级（prefetch-dependencies-oci-ta、buildah-oci-ta、 source-build-oci-ta、移除 show-sbom / summary）属于此技能的 --minor 加 MIGRATION.md 加 generatePipelineRuns.sh 流程。

优先使用 -oci-ta 任务变体

当 Konflux 目录同时提供基于工作区的任务和 <name>-oci-ta 变体时，在模板、共享流水线和 PLR 中优先使用 -oci-ta 套件。OCI-TA 任务通过 SOURCE_ARTIFACT / CACHI2_ARTIFACT 和 ociStorage 参数传递制品，而不是使用 source 工作区。

**Operator-bundle 例外：**除非用户明确要求修改 operator-bundle，否则不要在针对整个流的操作中将 rhdh-operator-bundle.yaml 或 rhdh-operator-bundle-* PLR 迁移到 -oci-ta 任务。Hub、operator、 must-gather 和 bootc 均在范围内。rhdh-rag-content-* 仅适用于 1.10 （已弃用；在 main / 2.1 中移除）。各变体的文件列表： konflux-rhdh-midstream.md。

旧版任务	首选 OCI-TA 任务
git-clone	git-clone-oci-ta
prefetch-dependencies	prefetch-dependencies-oci-ta
buildah	buildah-oci-ta
source-build	source-build-oci-ta
sast-snyk-check	sast-snyk-check-oci-ta
sast-shell-check	sast-shell-check-oci-ta
sast-unicode-check	sast-unicode-check-oci-ta
push-dockerfile	push-dockerfile-oci-ta

prefetch-dependencies → prefetch-dependencies-oci-ta（流水线任务名称可以保留为 prefetch-dependencies）：添加 SOURCE_ARTIFACT、 ociStorage、ociArtifactExpiresAfter、enable-package-registry-proxy； 移除 dev-package-managers 和 source 工作区；保留 git-basic-auth 和 netrc；将下游任务连接到 prefetch 的 SOURCE_ARTIFACT / CACHI2_ARTIFACT 结果。

OCI-TA 替换不会由 updateDigests.sh 处理——请应用任务当前 MIGRATION.md 中的参数和工作区要求，然后重新生成 PLR。

编写规则

编辑 .tekton YAML、提交、推送和创建拉取请求都属于写入操作。请遵循 /mutation-gate。

• 始终传入 --no-push / --nopush。除非用户明确提出要求，否则不要推送或创建 PR。generatePipelineRuns.sh 不会提交或推送。当用户确实要求创建 PR/MR 时，在 /mutation-gate 批准后，按名称调用 /rhdh-pr-mr。
• 此技能创建 PR 或 MR 时，标题末尾必须用方括号标明目标分支，例如 chore: update Konflux Tekton tasks [release-2.1]。目标分支为 main 时，使用 [main]。如果缺少该后缀，/rhdh-pr-mr 会追加。
• 正文中始终包含 https://github.com/redhat-developer/rhdh-skills/tree/main/skills/ci/rhdh-konflux-tasks。创建前，询问要引用哪个 Jira key。如果用户提供了 key，添加 https://redhat.atlassian.net/browse/<KEY> 并传入 --issue。如果用户未提供 key，或表示“no jira”，则省略 Jira 行，也不要传入 --issue。不要查找 key，也不要编造 key。
• 用 -oci-ta 替换旧任务时，先编辑模板和共享流水线，再重新生成 PLR（或手动修补内联的 pipelineSpec PLR）。只编辑 PLR 会导致事实来源过时。
• 只应用当前 MIGRATION.md 中记录的用户操作。跳过“无需操作”部分。不要编造会冻结流水线参数、导致下一次 Konflux 升级失败的 verify_* 守卫。务必针对当前可信任务列表运行 scripts/check-trusted-tasks.sh——这是 ECP 允许列表检查，不是参数漂移检查。
• 提交前，检查 git diff 中对 quay.io/konflux-ci/tekton-catalog/task-* 的更改。
• 完成 Tekton 检查后，按名称调用 /rhdh-base-images（不要调用其脚本路径）。将流映射到 main 或 release-*。提供命名明确的 rhdh、catalog 和 overlays 检出目录，以便该技能固定 builder.Containerfile / .nvm/ / overlays versions.json。不要在此技能中编辑这些文件。
• 由人工审核 .tekton/ 和 .tekton-templates/ 中的完整差异，并决定何时推送。

完成条件

满足以下条件后，更新才算完成：列出每个标签发生变更的任务及其旧标签和新标签，并为每项任务注明已应用的迁移，或说明无需迁移的原因；列出受影响的模板和共享流水线；凡模板或流水线参数发生变更之处，均已运行 generatePipelineRuns.sh 或 updatePLRs.sh（或在 1.9/1.10 上运行已弃用的 generatePipelineRunsForPlugins.sh）。说明哪些文件是重新生成的，哪些文件是手动编辑的。生成器绝不会处理 Variant B build-pipeline-*.yaml 文件。rhdh-rag-content-* 内联 pipelineSpec PLR 仅存在于 1.10（已弃用；在 main / 2.1 上已移除）；如有这些文件，应手动编辑，不要在 main 上查找。

scripts/check-trusted-tasks.sh（14 天时间范围）检查通过，或仅剩已记录的 expiring-no-successor / expired-no-successor 警告。应在面向用户的摘要中说明这些警告（到期日期、几天后重新运行、Slack #konflux-users）。不要将无后继任务警告当作调试信息处理。

必须针对映射后的 GitHub 分支运行 /rhdh-base-images（至少执行 analyze）。列出当前与最新的 FROM 标签、Node 头文件版本、头文件或 RPM 是否发生变化；对于 plugin-catalog，还要列出 builder.Containerfile 的 FROM 旧值→新值、.nvm/releases/ 是否与该映像中的 node --version 匹配，以及 grep konflux.additional-tags build/containerfiles/builder.Containerfile 是否包含与 .nvmrc 匹配的 node-v。如果跳过了该技能，说明原因（没有命名检出目录，且 /rhdh-context 未找到检出目录）。

说明提交状态，并明确说明没有推送，除非用户要求推送。指出任何无法查明的迁移文档，不要擅自假设升级无需操作。