Linux 核心的持續整合測試

CKI 團隊是如何防止 bug 被合併到 Linux 核心中。

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 個測試並將繼續開源更多測試。

參與其中

上游的核心測試工作日漸增多。包括 Google、Intel、Linaro 和 Sony 在內的許多公司為各種核心提供了測試輸出。每一項工作都專注於為上游核心以及每個公司的客戶群帶來價值。

如果你或者你的公司想要參與這一工作，請參加在 9 月份在葡萄牙里斯本舉辦的 Linux Plumbers Conference 2019。在會議結束後的兩天加入我們的 Kernel CI hackfest 活動，並推動快速核心測試的發展。

更多詳細資訊，請見我在 Texas Linux Fest 2019 上的演講。

---

via: https://opensource.com/article/19/6/continuous-kernel-integration-linux

作者：Major Hayden 選題：lujun9972 譯者：LazyWolfLin 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

訂閱“Linux 中國”官方小程式來檢視