rhdh-base-images

RHDH 基础镜像

使用随附的脚本，而不是重新构建特定于仓库的逻辑。

仓库检出是用户明确指定的输入。本技能不会发现其他技能的路径。

路由

意图	加载或运行
只读扫描当前/最新镜像	workflows/update-base-images.md，然后运行 scripts/base-images-and-rpms.sh --analyze ...
说明仓库规则	references/repos.md
预览更新	workflows/update-base-images.md，然后运行 scripts/base-images-and-rpms.sh --dry-run ...
更新镜像、锁文件、Node 头文件、目录构建器、覆盖层中的 Node 或 Go 工具链	workflows/update-base-images.md

扫描会按仓库报告：每个 FROM 镜像的当前标签和最新标签、文件内 UBI 次版本的差异、Node 或 Go 工具链的偏差、读取过的注册表和分支，以及无法读取的内容。

写入规则

任何检出、分支操作、文件编辑、依赖安装、提交、推送或 PR 都属于写入操作。先执行只读发现或 --dry-run，然后遵循 /mutation-gate：说明每项操作的目标仓库和分支（rhdh:release-1.10）、确切命令、将产生的更改，以及操作失败时其余操作的处理方式；取得对所述操作集合的批准；然后执行；最后报告每项操作是已完成、失败还是已跳过，以及其更改的资源和仍然存在的风险。

安装 rpm-lockfile-prototype、登录注册表、使用 --push 和创建 PR 都是各自独立的操作。默认采用本地操作，不推送；不要直接推送到受保护分支。写入前，确认分支存在且工作树干净。

用户批准后要求推送并创建 PR/MR 时，按名称调用 /rhdh-pr-mr（或其 create-pr-mr.sh），不要手动执行 gh pr create / glab mr create。如果已知 Jira 键，则传入 --issue；省略该参数即可跳过关联。在该路径迁移之前，中途的 updateBaseImages.sh 仍使用 distgit createPR.sh。

仓库不变量

• 可接受的分支选择器为 main 或 release-*；将它们映射到 references/repos.md 中记录的 GitLab scripts 分支。
• 使基础镜像的 UBI 次版本与 RPM 仓库 URL 保持一致。
• 重新生成 rpms.lock.yaml 前，将 rpms.in.yaml 中 OpenShift 客户端 N-el9-beta 的 baseurl 值及匹配的 rhocp-N-for-rhel-9-$basearch-rpms repoid 更新为仍存在于 mirror.openshift.com 上的最新已发布 4.y 流（例如，4.21-el9-beta → 4.22-el9-beta）。已发布的 4.y 名称来自以下链接中的产品生命周期 API：https://access.redhat.com/support/policy/updates/openshift#dates。不要切换到尚未发布的目录，例如 4.23-el9-beta 或 5.1-el9-beta。如果获取生命周期信息失败，或镜像站上没有已发布的 4.y 目录，则保持 rpms.in.yaml 不变。若文件中没有此类仓库，则跳过。
• 如果本次运行包含 plugin-catalog checkout，则将 build/containerfiles/builder.Containerfile 中的 /rhocp/4.N/ 路径段改为同一最新已发布的 4.y（例如，/rhocp/4.21/ → /rhocp/4.22/）。保持 ocp-tools URL 不变。若获取生命周期信息失败，则不要改写。
• 如果本次运行中该 Containerfile 有更改，则将其 release="N" 标签及 konflux.additional-tags 中匹配的 X.Y-N 标记各递增一次（release="3" 和 2.2-3 变为 release="4" 和 2.2-4）。将 version=、rhdh.version= 和 node-v* 留给 node-header 改写处理。对每个 .tekton/plugin-catalog-builder*.yaml 中的 build-source-image 任务，将 BASE_IMAGES 设置为 Containerfile 的 FROM 镜像；若缺少该参数，则添加。Containerfile 未更改时，不要递增 release。
• 当 RPM Containerfile 使用 dnf/microdnf install --installroot（operator 空 rootfs）时，使用 rpm-lockfile-prototype --bare 重新生成锁文件，以锁定完整依赖闭包（glibc、coreutils、bash）。不要传入 -f；它会加载 UBI rpmdb 并省略这些软件包。对基础镜像进行分层安装时仍使用 -f。如果求解失败（nothing provides、conflicting requests），还原 rpms.lock.yaml / rpms.in.yaml，且不要推送。
• 在 RHDH 上，当 builder 镜像变更 Node 版本时，更新 Node headers。然后，如果这些 checkout 在处理范围内，将 plugin-catalog 的 build/containerfiles/builder.Containerfile FROM 固定到相同的 UBI Node tag@sha256。Catalog headers 应与该 Containerfile 将运行的 Node 版本一致：镜像中的 node --version；或者，如果文件在 headers RUN 之前通过 dnf 安装了 nodejs，则使用 dnf repoquery 得到的较新 nodejs RPM 版本。不要将较旧的 rhdh .nvm/ 复制到该版本上。将 konflux.additional-tags 中的 node-v* 改写为与 catalog .nvmrc 一致，并将 overlays versions.json 中的 node 设为 rhdh .nvmrc 的值。 Catalog 将 release-1.Y 映射到 GitLab rhdh-1.Y-rhel-9，将 release-2.Y 映射到 GitLab release-2.Y（使用 UBI10 / RHEL10）。Catalog 没有 rpms.lock.yaml。不要在 catalog builder commit 中添加 [skip-build]。
• 在 rhdh-operator main 上，如果 Go toolset 镜像更新，则将 go.mod 升级到该镜像的版本。在 rhdh-must-gather 的 main 和 release-2.* 上，同样根据根目录 Containerfile 中的 ubi9/go-toolset 或 ubi10/go-toolset 镜像更新；若 go.mod 没有 toolchain 行，则添加。跳过 must-gather release-1.*（没有 Go module）。绝不要为了匹配较旧镜像而降低 go 或 toolchain 版本；更新的固定版本（例如来自 Renovate）是有效的。
• 从镜像扫描中排除 RHDH 的 e2e-tests/ 和 .ci/。
• 忽略 rpm-lockfile-prototype 中匹配 No sources found for 或 "no matching sources" 的行。这些源 RPM 往往尚未发布；二进制锁文件仍然有效。不要将它们报告为未读取、失败或剩余风险。 另一个技能会按名称调用 /rhdh-base-images，并使用它报告的内容；它不会直接访问这些脚本路径。/rhdh-konflux-tasks 会在流式 Konflux 升级期间执行此操作，以确保 Node 头文件与构建器映像匹配；它会传入命名检出项以及 main 或 release-* 选择器。

完成标准

只有在以下条件全部满足时，分析才算完成：列出范围内的每个仓库及其当前标签和最新标签；说明 UBI 版本差异和工具链偏移，或明确说明没有差异；并将扫描无法读取的每个注册表、锁文件或分支标记为未读取，而不是报告为最新。经过筛选的 No sources found for / "no matching sources" 行不属于未读取内容，应从报告中省略。

只有在以下条件全部满足时，更新才算完成：在进行任何编辑之前，已在干净的工作树中验证目标分支存在；已按目标和结果报告每项获准操作；并明确说明推送和 PR 状态，包括保留默认本地行为时注明“未推送”。当 Node 头文件 / .nvmrc 发生更改时，列出插件目录的 FROM 旧值→新值，确认 grep konflux.additional-tags build/containerfiles/builder.Containerfile 中的 node-v 与 .nvmrc 相匹配，并列出 overlays versions.json 中的 node 值（或说明这些检出项不在范围内）。当目录构建器 Containerfile 发生更改时，列出 release 旧值→新值，并确认构建器 PipelineRun 的 BASE_IMAGES 与该文件的 FROM 相匹配（或说明 Containerfile 未发生更改）。