Linux 內核的每個發佈版本包含了來自 1,700 個開發者產生的 14,000 個變更集，很顯然，這使得 Linux 內核快速迭代的同時也產生了巨大的複雜性問題。內核上 Bug 有小麻煩也有大問題，有時是系統崩潰，有時是數據丟失。
隨著越來越多的項目對於持續集成（CI）的呼聲，內核持續集成（CKI）小組秉承著一個任務目標：防止 Bug 被合併到內核當中。
Linux 測試問題
許多 Linux 發行版只在需要的時候對 Linux 內核進行測試。而這種測試往往只在版本發佈時或者用戶發現錯誤時進行。
有時候，出現玄學問題時，維護人員需要在包含了數萬個補丁的變更中匆忙地尋找哪個補丁導致這個新的玄學 Bug。診斷 Bug 需要專業的硬件設備、一系列的觸發器以及內核相關的專業知識。
CI 和 Linux
許多現代軟件代碼庫都採用某種自動化 CI 測試機制，能夠在提交進入代碼存儲庫之前對其進行測試。這種自動化測試使得維護人員可以通過查看 CI 測試報告來發現軟件質量問題以及大多數的錯誤。一些簡單的項目，比如某個 Python 庫，附帶的大量工具使得整個檢查過程更簡單。
在任何測試之前都需要配置和編譯 Linux。而這麼做將耗費大量的時間和計算資源。此外，Linux 內核必需在虛擬機或者裸機上啟動才能進行測試。而訪問某些硬件架構需要額外的開銷或者非常慢的仿真。因此，人們必須確定一組能夠觸發錯誤或者驗證修復的測試集。
CKI 團隊如何運作？
Red Hat 公司的 CKI 團隊當前正追蹤來自數個內部內核分支和上游的穩定內核分支樹等內核分支的更改。我們關注每個代碼庫的兩類關鍵事件：
1. 當維護人員合併 PR 或者補丁時，代碼庫變化後的最終結果。
2. 當開發人員通過拼湊或者穩定補丁隊列發起變更合併時。
當這些事件發生時，自動化工具開始執行，GitLab CI 管道開始進行測試。一旦管道開始執行 linting 腳本、合併每一個補丁，併為多種硬件架構編譯內核，真正的測試便開始了。我們會在六分鐘內完成四種硬件架構的內核編譯工作，並且通常會在兩個小時或更短的時間內將反饋提交到穩定郵件列表中。（自 2019 年 1 月起）每月執行超過 100,000 次內核測試，並完成了超過 11,000 個 GitLab 管道。
每個內核都會在本地硬件架構上啟動，其中包含：
◈ aarch64：64 位 ARM，例如 Cavium（當前是 Marvell）ThunderX。
◈ ppc64/ppc64le：大端和小端的 IBM POWER 系統。
◈ s390x：IBM Zseries 大型機
◈ x86_64：Intel 和 AMD 工作站、筆記本和服務器。
這些內核上運行了包括 Linux 測試項目（LTP）在內的多個測試，其中包括使用常用測試工具的大量測試。我們 CKI 團隊開源了超過 44 個測試並將繼續開源更多測試。
via: https://opensource.com/article/19/6/continuous-kernel-integration-linux
作者：Major Hayden 選題：lujun9972 譯者：LazyWolfLin 校對：wxy
