Fedora 45 發行流程與建置流水線

Fedora 45 發行流程與建置流水線

Fedora 45 透過一個高度自動化的流水線將原始碼轉換為可安裝的產物，該流程涉及原始碼控制、淨室建置 (clean-room builds)、門檻更新 (gated updates) 以及多階段的組合過程。此系統確保每一個 ISO、雲端映像檔和容器映像檔在交付給終端用戶之前，都是可重現、可審核且經過測試的。

原始碼控制與套件定義

Fedora 在託管於 src.fedoraproject.org 的個別 Git 儲存庫中管理套件定義（正在從 Pagure 遷移至 Forgejo）。每個儲存庫包含一個 RPM spec 檔案、下游補丁 (downstream patches) 以及一個指向 lookaside cache 中上游 tarballs 的 sources 檔案，以避免將二進位檔案存入 Git。

打包者主要使用 fedpkg CLI 來管理這些儲存庫。當打包者執行 fedpkg build 時，該工具會生成一個指向特定 Git commit 的 URL 並提交給 Koji，確保建置可以從該 commit hash 完全重現。

建置系統：Koji

Koji 是 Fedora 的中央建置系統。它採用星狀架構 (hub-and-spoke architecture)，由一個被動的 XML-RPC 伺服器管理 PostgreSQL 資料庫，而建置守護行程 (builder daemons) 則會向此中心輪詢工作任務。

為了確保可重現性，Koji 會為每次建置創建一個全新的 Mock chroot 環境，防止來自先前建置的「洩漏」。系統使用 tags（建置的命名集合）來組織建置。建置目標 (build targets) 將請求映射到一個建置標籤（定義 buildroot）和一個目的地標籤（完成後的 RPM 存放處）。Koji 還透過插件協調非 RPM 產物，用於 Kiwi 映像檔、Image Builder 和 OSTree 組合。

更新門檻：Bodhi

對於分支發行版，RPM 不會直接從 Koji 移至用戶端。相反地，它們受到 Bodhi（更新管理系統）的門檻限制。Bodhi 管理更新經過三個狀態的轉換：待處理 (pending)、測試中 (testing) 和穩定 (stable)。

更新根據「業績值」(karma，來自用戶與自動化測試的反饋) 和在測試中停留的時間來趨向穩定。關鍵路徑套件（對開機和基本功能至關重要的套件）面臨更嚴格的要求，包括更長的測試期（14 天對比 7 天）和更高的業績值門檻。Bodhi 與 Greenwave 和 ResultsDB 整合進行 CI 門檻控制，一旦更新被標記為穩定，Bodhi 就會調用 Pungi 來組合實際的 DNF 儲存庫。

發行組合：Pungi

Pungi 是協調各種工具的編排者，將個別的 RPM 轉換為最終產品，如 ISO 和雲端映像檔。該過程遵循嚴格的順序以保持一致性：

1. 套件集凍結 (Pkgset)

Pungi 首先對特定的 Koji tag 進行快照。這個 Pkgset 階段確保後續所有步驟都使用凍結的套件集，使整個組合過程可審核，並防止新的 Koji 建置混入進行中的發行版中。

2. 產品定義 (Comps and Variants)

Pungi 使用兩個 XML 輸入來決定產品組成：

  • Comps (fedora-comps)： 定義套件群組（例如 gnome-desktop）以及每個套件的角色（強制、預設、選用或條件式）。
  • Variants XML： 定義特定產品（例如 Workstation, Server, Silverblue）以及它們包含哪些 comps 群組。

3. 開機映像檔與 ISO 生產

  • Buildinstall： 使用 lorax 創建 boot.iso，這是啟動 Anaconda 安裝程式的最小映像檔。這是所有安裝 ISO 的基礎。
  • Createiso： 使用 xorriso 將套件和儲存庫元數據疊加到 boot.iso 上，以產出最終的 dvd.iso（主要用於 Server 變體）。

4. 特殊映像檔建置

Fedora 為非傳統 ISO 提供三條主要路徑：

  • Kiwi： 建置雲端映像檔 (AWS, Azure, GCP)、Vagrant boxes、容器基礎映像檔和 WSL 映像檔。它使用 XML 定義，並透過 kiwiBuild 任務類型與 Koji 整合。
  • Image Builder： 基於 osbuild，處理基於 OSTree 和 bootc 的產物，包括 Atomic Desktop ISO、Fedora IoT 和 Fedora Minimal。它使用沙盒化階段的流水線來處理 JSON 清單。
  • rpm-ostree： 對於 Atomic Desktops (Silverblue, Kinoite 等)，rpm-ostree compose tree 根據 YAML treefiles 創建一個版本化、帶有校驗碼的檔案系統樹 (一個 OSTree commit)。comps-sync.py 腳本確保這些 treefiles 與標準的 comps XML 定義保持同步。

元數據與驗證

每次組合都會透過 productmd 函式庫生成標準化的元數據，產出如 composeinfo.json、images.json 和 rpms.json 等檔案。這些檔案對下游工具至關重要：Anaconda 使用它們來尋找安裝樹，而 openQA 使用它們來定位測試用的映像檔。

使用 openQA 進行自動化測試

組合完成後，openQA 會在虛擬機中啟動映像檔以執行自動化場景，包括安裝工作流、桌面功能和升級路徑。每晚的 Rawhide 和里程碑組合 (Beta, Final) 都會觸發 openQA 運行，在此發現的阻斷性錯誤 (blocking bugs) 可能會停止發行。

治理：變更流程 (Changes Process)

對 Fedora 流水線或系統預設值的重大修改透過 Changes 流程進行管理。提案被分為 System-Wide（需要 FESCo 批准和詳細的應變計畫）或 Self-Contained（範圍限於特定套件）。所有變更必須在 Rawhide 中實施，並滿足特定截止日期（如 Beta Freeze）才能包含在發行版中。

來自社群的技術洞察

社群討論強調了這種端到端可見度對於故障排除的重要性。一位貢獻者指出，了解映像檔生產流水線對於診斷版本之間變化的檔案系統權限問題至關重要。然而，關於 Koji 的淨室建置也提供了一些歷史背景，一位用戶指出，在過去，未列在 Build-Requires 中的依賴項有時可能會因為環境狀態而洩漏到建置中，儘管這在現代版本中較少見。

Sources