Fedora 45 リリースプロセスとビルドパイプライン

Fedora 45は、ソース管理、クリーンルームビルド、ゲート付きアップデート、および多段階のコンポジションプロセスを含む高度に自動化されたパイプラインを通じて、ソースコードをインストール可能なアーティファクトへと変換します。このシステムにより、すべてのISO、クラウドイメージ、およびコンテナイメージが、エンドユーザーに届く前に再現可能で、監査可能であり、テストされていることが保証されます。

ソース管理とパッケージ定義

Fedoraは、src.fedoraproject.org（PagureからForgejoへ移行中）でホストされている個別のGitリポジトリでパッケージ定義を管理しています。各リポジトリには、RPM specファイル、ダウンストリームパッチ、およびバイナリファイルをGitから除外するためにルックサイドキャッシュ内のアップストリームtarballを指すsourcesファイルが含まれています。

パッケージ作成者は、主にfedpkg CLIを使用してこれらのリポジトリを管理します。パッケージ作成者がfedpkg buildを実行すると、ツールは特定のGitコミットを指すURLを生成し、それをKojiに送信します。これにより、そのコミットハッシュからビルドが完全に再現可能であることが保証されます。

ビルドシステム: Koji

Kojiは、Fedoraの中央ビルドシステムとして機能します。これは、パッシブなXML-RPCサーバーがPostgreSQLデータベースを管理し、ビルダーデーモンが作業のためにこのハブをポーリングする、ハブ・アンド・スポーク型アーキテクチャを採用しています。

再現性を確保するために、Kojiはビルドごとに新しいMock chroot環境を作成し、以前のビルドからの「漏洩」を防ぎます。システムは、ビルドの集合体であるタグを使用してビルドを整理します。ビルドターゲットは、リクエストをビルドタグ（ビルドルートを定義）とデスティネーションタグ（完成したRPMが配置される場所）にマッピングします。また、KojiはKiwiイメージ、Image Builder、およびOSTreeコンポーズ用のプラグインを介して、非RPMアーティファクトのオーケストレーションも行います。

アップデートゲーティング: Bodhi

ブランチリリースの場合、RPMはKojiからユーザーへ直接移動するわけではありません。代わりに、アップデート管理システムであるBodhiによってゲート（制限）が設けられています。Bodhiは、アップデートの遷移を「pending（保留中）」、「testing（テスト中）」、「stable（安定）」の3つの状態で管理します。

アップデートは、「karma」（ユーザーおよび自動テストのフィードバック）とテストに費やされた時間に基づいて安定へと進みます。クリティカルパスのパッケージ（起動や基本機能に不可欠なもの）には、より長いテスト期間（7日間ではなく14日間）や高いkarmaしきい値を含む、より厳格な要件が課されます。Bodhiは、CIゲーティングのためにGreenwaveおよびResultsDBと統合されており、アップデートがstableとしてマークされると、BodhiはPungiを呼び出して実際のDNFリポジトリをコンポーズします。

リリースコンポジション: Pungi

Pungiは、個々のRPMをISOやクラウドイメージなどの最終製品に変換するために、さまざまなツールを調整するオーケストレーターです。プロセスは一貫性を維持するために厳格な順序に従います：

1. パッケージセットの凍結 (Pkgset)

Pungiは、まず特定のKojiタグのスナップショットを作成します。このPkgsetフェーズにより、以降のすべてのステップで凍結されたパッケージセットが使用されることが保証され、コンポーズ全体が監査可能になり、進行中のリリースに新しいKojiビルドが紛れ込むのを防ぎます。

2. 製品定義 (Comps and Variants)

Pungiは、製品の構成を決定するために2つのXML入力を使用します：

• Comps (fedora-comps): パッケージグループ（例：gnome-desktop）と各パッケージの役割（必須、デフォルト、オプション、または条件付き）を定義します。
• Variants XML: 特定の製品（例：Workstation、Server、Silverblue）と、それらが含むcompsグループを定義します。

3. ブートイメージおよびISOの作成

• Buildinstall: loraxを使用して、Anacondaインストーラーを起動するための最小イメージであるboot.isoを作成します。これはすべてのインストーラーISOの基盤となります。
• Createiso: xorrisoを使用して、パッケージとリポジトリのメタデータをboot.isoにオーバーレイし、最終的なdvd.iso（主にServerバリアント用）を生成します。

4. 特殊なイメージビルド

Fedoraは、非伝統的なISOに対して主に3つのパスを使用しています：

• Kiwi: クラウドイメージ（AWS、Azure、GCP）、Vagrantボックス、コンテナベースイメージ、およびWSLイメージをビルドします。XML定義を使用し、kiwiBuildタスクタイプを介してKojiと統合されています。
• Image Builder: osbuildに基づいており、Atomic Desktop ISO、Fedora IoT、Fedora Minimalを含む、OSTreeベースおよびbootcベースのアーティファクトを処理します。JSONマニフェストを処理するために、サンドボックス化されたステージのパイプラインを使用します。
• rpm-ostree: Atomic Desktop（Silverblue、Kinoiteなど）の場合、rpm-ostree compose treeがYAMLツリーファイルに基づいて、バージョン管理されチェックサムされたファイルシステムツリー（OSTreeコミット）を作成します。comps-sync.pyスクリプトにより、これらのツリーファイルが標準のcomps XML定義と同期されていることが保証されます。

メタデータと検証

すべてのコンポーズは、productmdライブラリを介して標準化されたメタデータを生成し、composeinfo.json、images.json、rpms.jsonなどのファイルを作成します。これらのファイルは、ダウンストリームツールにとって極めて重要です。Anacondaはインストールツリーを見つけるためにこれを使用し、openQAはテスト用のイメージを特定するためにこれを使用します。

openQAによる自動テスト

コンポーズが完了すると、openQAが仮想マシン内でイメージを起動して、インストールワークフロー、デスクトップ機能、アップグレードパスを含む自動シナリオを実行します。毎晩のRawhideおよびマイルストーンコンポーズ（Beta、Final）では常にopenQAの実行がトリガーされ、ここで発見された致命的なバグはリリースを停止させる可能性があります。

ガバナンス: Changesプロセス

Fedoraのパイプラインまたはシステムデフォルトへの大幅な変更は、Changesプロセスを通じて管理されます。提案は、System-Wide（FESCoの承認と詳細なコンティンジェンシープランが必要）またはSelf-Contained（特定のパッケージに限定）に分類されます。すべての変更はRawhideに実装され、リリースに含まれるためには特定の期限（Beta Freezeなど）を満たす必要があります。

コミュニティからの技術的洞察

コミュニティの議論では、トラブルシューティングにおけるこのエンドツーエンドの可視性の重要性が強調されています。ある貢献者は、イメージ作成パイプラインを理解することは、バージョン間で変更されるファイルシステムの権限問題を診断するために不可欠であると述べています。しかし、Kojiのクリーンルームビルドに関しては、過去の文脈として、以前は環境の状態によりBuild-Requiresに記載されていない依存関係がビルドに混入することがあったかもしれないという指摘もありましたが、現代の構成ではこれはあまり一般的ではありません。