核心持續整合（CKI）專案旨在防止錯誤進入 Linux 核心。
在 Linux 核心的持續整合測試 一文中，我介紹了 核心持續整合（CKI）專案及其使命：改變核心開發人員和維護人員的工作方式。本文深入探討了該專案的某些技術方面，以及這所有的部分是如何組合在一起的。
核心中每一項令人興奮的功能、改進和錯誤都始於開發人員提出的更改。這些更改出現在各個核心儲存庫的大量郵寄清單中。一些儲存庫關注核心中的某些子系統，例如儲存或網路，而其它儲存庫關注核心的更多方面。 當開發人員向核心提出更改或修補程式集時，或者維護者在儲存庫本身中進行更改時，CKI 專案就會付諸行動。
CKI 專案維護的觸發器用於監視這些修補程式集並採取措施。諸如 Patchwork 之類的軟體專案通過將多個修補程式貢獻整合為單個修補程式系列，使此過程變得更加容易。修補程式系列作為一個整體歷經 CKI 系統，並可以針對該系列發布單個報告。
其他觸發器可以監視儲存庫中的更改。當核心維護人員合併修補程式集、還原修補程式或建立新標籤時，就會觸發。測試這些關鍵的更改可確保開發人員始終具有堅實的基線，可以用作編寫新修補程式的基礎。
所有這些更改都會進入 GitLab CI 管道，並歷經多個階段和多個系統。
首先要準備好要編譯的原始碼。這需要克隆儲存庫、打上開發人員建議的修補程式集，並生成核心組態檔。這些組態檔具有成千上萬個用於開啟或關閉功能的選項，並且組態檔在不同的系統體系結構之間差異非常大。 例如，一個相當標準的 x86_64 系統在其組態檔中可能有很多可用選項，但是 s390x 系統（IBM zSeries 大型電腦）的選項可能要少得多。在該大型電腦上，某些選項可能有意義，但在消費類筆記型電腦上沒有任何作用。
核心進一步轉換為原始碼工件。該工件包含整個儲存庫（已打上修補程式）以及編譯所需的所有核心組態檔。 上游核心會打包成壓縮包，而 Red Hat 的核心會生成下一步所用的原始碼 RPM 包。
編譯核心會將原始碼轉換為計算機可以啟動和使用的程式碼。組態檔描述了要構建的內容，核心中的指令碼描述了如何構建它，系統上的工具（例如 GCC 和 glibc）完成構建。此過程需要一段時間才能完成，但是 CKI 專案需要針對四種體系結構快速完成：aarch64（64 位 ARM）、ppc64le（POWER）、s390x（IBM zSeries）和 x86_64。重要的是，我們必須快速編譯核心，以便使工作任務不會積壓，而開發人員可以及時收到反饋。
新增更多的 CPU 可以大大提高速度，但是每個系統都有其局限性。CKI 專案在 OpenShift 的部署環境中的容器內編譯核心；儘管 OpenShift 可以實現高伸縮性，但在部署環境中的可用 CPU 仍然是數量有限的。CKI 團隊分配了 20 個虛擬 CPU 來編譯每個核心。涉及到四個體系結構，這就漲到了 80 個 CPU！
另一個速度的提高來自 ccache 工具。核心開發進展迅速，但是即使在多個發布版本之間，核心的大部分仍保持不變。ccache 工具進行編譯期間會在磁碟上快取已構建的物件（整個核心的一小部分）。稍後再進行另一個核心編譯時，ccache 會查詢以前看到的核心的未更改部分。ccache 會從磁碟中提取快取的物件並重新使用它。這樣可以加快編譯速度並降低總體 CPU 使用率。現在，耗時 20 分鐘編譯的核心在不到幾分鐘的時間內就完成了。
核心進入最後一步：在真實硬體上進行測試。每個核心都使用 Beaker 在其原生體系結構上啟動，並且開始無數次的測試以發現問題。一些測試會尋找簡單的問題，例如容器問題或啟動時的錯誤訊息。其他測試則深入到各種核心子系統中，以查詢系統呼叫、記憶體分配和執行緒中的回歸問題。
大型測試框架，例如 Linux Test Project（LTP），包含了大量測試，這些測試在核心中尋找麻煩的回歸問題。其中一些回歸問題可能會回滾關鍵的安全修復程式，並且進行測試以確保這些改進仍保留在核心中。
測試完成後，關鍵的一步仍然是：報告。核心開發人員和維護人員需要一份簡明的報告，準確地告訴他們哪些有效、哪些無效以及如何獲取更多資訊。每個 CKI 報告都包含所用原始碼、編譯引數和測試輸出的詳細資訊。該資訊可幫助開發人員知道從哪裡開始尋找解決問題的方法。此外，它還可以幫助維護人員在漏洞進入核心儲存庫之前知道何時需要保留修補程式集以進行其他檢視。
CKI 專案團隊通過向核心開發人員和維護人員提供及時、自動的反饋，努力防止錯誤進入 Linux 核心。這項工作通過發現導致核心錯誤、安全性問題和效能問題等易於找到的問題，使他們的工作更加輕鬆。