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 の作成を依頼した場合は、gh pr create や glab mr create を独自に実行するのではなく、名前で /rhdh-pr-mr（またはその create-pr-mr.sh）を呼び出してください。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 の名称は、https://access.redhat.com/support/policy/updates/openshift#dates にリンクされている製品ライフサイクル API から取得します。4.23-el9-beta や 5.1-el9-beta などの未リリースディレクトリには移行しないでください。ライフサイクル情報の取得に失敗した場合、またはリリース済み 4.y ディレクトリがミラー上にない場合は、rpms.in.yaml を変更しないでください。そのようなリポジトリがファイルにない場合はスキップしてください。
• 実行対象に plugin-catalog のチェックアウトが含まれる場合は、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 を使う場合（空の rootfs を持つ operator）は、rpm-lockfile-prototype --bare でロックファイルを再生成し、完全な依存関係一式（glibc、coreutils、bash）をロックしてください。-f は UBI の rpmdb を読み込み、これらのパッケージを除外するため、指定しないでください。ベースイメージへのレイヤーインストールでは、引き続き -f を使ってください。依存関係の解決に失敗した場合（nothing provides、conflicting requests）は、rpms.lock.yaml／rpms.in.yaml を元に戻し、プッシュしないでください。
• RHDH では、ビルダーイメージで Node が変更された場合に Node ヘッダーを更新してください。その後、対象のチェックアウトに含まれる場合は、plugin-catalog の build/containerfiles/builder.Containerfile の FROM を同じ UBI Node の tag@sha256 に固定してください。カタログのヘッダーは、その Containerfile が実行する Node バージョンに合わせます。これはイメージの node --version、またはヘッダーの RUN より前にファイルが dnf で nodejs をインストールする場合は、dnf repoquery で取得した新しい nodejs RPM のバージョンです。古い rhdh .nvm/ をそのバージョンに上書きコピーしないでください。konflux.additional-tags の node-v* をカタログの .nvmrc に合わせて書き換え、オーバーレイの versions.json の node を rhdh の .nvmrc の値に設定してください。 カタログでは release-1.Y を GitLab の rhdh-1.Y-rhel-9 に、release-2.Y を GitLab の release-2.Y に対応付けます（UBI10／RHEL10 を使用）。カタログには rpms.lock.yaml がありません。カタログビルダーのコミットに [skip-build] を付けないでください。
• rhdh-operator の main では、イメージの Go ツールセットが新しい場合、go.mod をそのバージョンに引き上げてください。古いイメージに合わせて go や toolchain を下げないでください。より新しい固定バージョン（例：Renovate による更新）は有効です。
• RHDH の e2e-tests/ と .ci/ はイメージスキャンの対象から除外してください。
• No sources found for または "no matching sources" に一致する rpm-lockfile-prototype の行は無視してください。これらのソース 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 に .nvmrc と一致する node-v が含まれていることを確認して、オーバーレイの versions.json の node 値を明記します（または、これらのチェックアウトが対象範囲外であることを明記します）。カタログビルダーの Containerfile が変更された場合は、release の旧→新を明記し、ビルダーの PipelineRun の BASE_IMAGES がそのファイルの FROM と一致していることを確認します（または、Containerfile が変更されていないことを明記します）。