編者按：在海量的代碼測試和構建中， CI(Continuous Integration)在代碼提交階段，對提高軟件質量和開發效率起到了至關重要的作用。2023 龍蜥操作系統大會全面繁榮開發者生態分論壇上，龍蜥社區 QA SIG Maintainer、聯通數科 CUlinux 測試負責人宋彥嶺從龍蜥社區質量體系、CI 架構、CI 服務流程及 CI 接入等方面進行介紹，充分展示出社區 CI 在龍蜥開源操作系統質量保障上的重要程度。

 (圖/龍蜥社區 QA SIG Maintainer、聯通數科 CUlinux 測試負責人宋彥嶺)

社區質量體系

一般來説，操作系統版本發佈週期可以分為三部分：第一是日常開發。日常開發過程中由代碼提交觸發的 CI 測試，包含 Kernel CI、Package CI、Docker CI、OOT CI，這也是目前 CI 服務體系的四項主要內容。第二是日常集成。該過程中由日常的定時任務來觸發 Nightly 測試。第三是產品發佈，包含功能、性能、兼容性、穩定性等測試。 我們可以看到，作為操作系統服務的第一道防線，CI 測試的意義非常重大：

• 統一標準規範：所有開發者按照社區標準規範提交代碼，既改善了研發流程，又滿足開源合規需求。
• 提前預知缺陷：在代碼提交階段就進行代碼測試，提前暴露代碼質量問題，減少後續測試壓力，提升產品質量。
• 全自動無感知：在社區提交的 PR 只要符合規範均自動觸發 CI 測試，降低開發者使用門檻，提升研發效率。

目前，龍蜥社區 CI 架構如上圖，首先社區 代碼倉庫主要來自於 Gitee 或 Github 的公開倉庫，這些倉庫通過 webhook 接入到社區 CI 服務體系中，接入的倉庫若有新事件，如新代碼合入、PR 評論等會觸發 webhook 消息傳遞，將消息傳遞給 git 解析器，解析成標準的數據後進行邏輯處理。其次 CI 通過提前接入體系中的 SDK 去調度具體的任務，例如基於 T-One 平台的測試任務，或基於 ABS 平台的構建任務。最終 T-One、ABS 等平台會將任務結果返回，CI 服務通過標準回調處理，以評論的形式將結果呈現在對應的 PR 上。

在開發者的角度上，該體系由託管在 Gitee 或者 Github 上的代碼，基於 CI 機器人、配置中心或 T-One、ABS 平台等基礎設施，實現一系列 CI 服務。它處於自動化無感知的狀態，更像是一個黑盒子。

CI 基礎設施中，有關測試方面的核心在 T-One 測試平台完成，該平台集成了行業內通用的測試用例，如模糊測試、性能測試用例等，也可以由社區開發者自定義一些測試用例加入到 T-One 中，實現自動化運行。目前，T-One 已覆蓋業界主流通用 OS 以及混合的硬件架構測試，支持動態擴展，利用動態擴展創建雲資源，並且作為測試資源使用。

ABS 作為構建核心平台，覆蓋 Anolis OS 及主流的硬件架構，可以實現對社區開源軟件包的構建，同時將構建成功的軟件包對象發佈到公網環境中。

社區 CI 體系特色分為四大部分：第一是分層分級，針對不同倉庫可以進行分層分級處理，普通倉庫提供基本 CI 測試，核心倉庫提供定製化的 CI 測試能力。第二是可拓展框架，CI 工具提供了插件化能力，多種工具可以組合產生聯動效果，其中新增功能可以通過插件進行快速擴展。第三是接入能力，提供高度開放的接入能力，可以讓開發者自定義開發測試來接入 CI 服務體系。第四是 CI/CD服務一體化，提供 PR 合入後的後續操作，根據倉庫類型不同提供不同的處理能力。

CI 服務流程

CI 服務階段從代碼提交到觸發 CI 測試，再由 reviewer 評審，測試失敗後需要進行重新測試，也可以通過評論方式重新觸發測試，評審通過則會合入 PR。
在上文中提到，CI 測試流程共有 Kernel CI、Package CI、Docker CI、OOT CI 4 種。Kernel CI 針對內核做 CI 測試，目前主要監測存放在 Gitee 上的 Cloud Kernel 倉庫，若4.19、5.10、6.6 三個內核一旦有新的代碼合入，由 CI 機器人進行檢查 CLA 簽署協議以及 PR 信息是否符合規範。再通過 CBC 工具以及 T-One 測試平台對新提交的 PR 進行測試，檢測沒有問題後，CI 機器人合入 PR 到指定倉庫並進行自動簽名操作。

CBC 與 T-One 測試部分主要測試項詳見下圖：

針對軟件包的 Package CI，對存放在 Gitee 上的 src-anolis-os、src-anolis-sig、src-anolis-module、src-anolis-ai 等多個倉庫組下的所有倉庫進行檢測。一旦發現新提交的 PR，先對基本信息進行檢測，由 T-One 進行合規檢查和代碼檢查，檢查測試無誤後由 ABS 構建出初步使用的軟件包，再交給 T-One 做冒煙測試。後續如果沒有問題，最後再由 ABS 構建出正式的軟件包，並推送到 mirrors 倉庫中。

Package CI 整個測試項詳見下圖：

針對容器鏡像的 Docker CI，檢測 baseos、app、dragonwell、language 存放在 Gitee 和 Github 公開倉庫的容器倉庫，一旦有新的 PR，會檢查 CLA 和容器的配置文件，檢測沒有問題後，會先通過 ABS 構建出測試使用的容器，由 T-One 做進一步測試，測試沒有問題會合入，通過 ABS 構建出正式的鏡像，推送到公網的鏡像倉庫中。
對於容器的測試詳見下圖：

針對內核的第三方模塊做的 CI 測試 - OOT CI ，檢測倉庫主要在 anolis 下以 kmod 開頭的第三方模塊的倉庫，這些倉庫中有新的 PR 產生，（該測試更輕量，與內核測試類似）先檢查 CLA，通過 T-One 進行 checkpatch 檢查和生成臨時分支 rpm tree，然後通過 ABS 構建出新的 OOT 模塊進行測試。

社區CI接入

下面介紹社區的開發者來自定義去接入 CI 流程的方法。首先在 Gitee 上建立了一個倉庫 ci-meta，是針對 CI 服務體系建立的 CI 配置中心。倉庫目錄結構如下圖，主要包括公共配置和開發者自定義的配置兩大部分。其中公共配置中包含三部分：產品相關的配置、 T-One 平台測試配置、全局倉庫配置，其中倉庫配置中包含了代碼檢查、ABS 構建的選項、依賴測試等。

若開發者想自己定義新的 CI 測試，則需要定義 CI 的 yaml 文件，將其存放在 CI 配置中心，其中的自定義目錄 repos 則會根據首字母建立不同的目錄，將相對應的軟件包  CI  yaml 文件存放，就可以接入到社區的 CI 服務中進行測試。該文件中的組成分為三部分，包括倉庫配置、測試配置和通知配置。若在 ci.yaml 缺失的情況下，默認引用全局配置，包括與 T-One 的交互或自定義的參數。通知配置目前支持兩種方式：郵件和釘釘，集成接入後在指定狀態時進行通知。

目前，在上述四種 CI 服務中，Kernel CI 和 Package CI 屬於常用服務，攔截了大量有問題的 PR，檢測了 6.5 萬 + patch，攔截了 1 萬+ patch，通過 T-One 平台發起了 7萬+ 測試任務，通過 ABS 平台發起了 2.1 萬＋ 構建任務。

未來，社區關於 CI 服務體系發展有以下展望：第一方面擴大支撐，未來會支持更多倉庫來進行定製化的 CI 測試，提供更強大的測試能力。第二部分是可視化，希望打造一個全新的可視化 web 界面，幫助開發者理解和縱覽社區服務，也降低接入 CI 體系的難度，通過可視化界面來完成點擊接入方式。第三部分完善接入，提供體驗更好的接入方式，提供更多的 CI 模式，完善開源社區的 CI 服務體系。第四部分是能力開放，提供工具封裝級別的插件支持，允許開發者自定義 CI 測試流程和工具模組，自行組裝和定製化 CI 流程步驟。

落地實踐

由於操作系統版本發佈週期相似，聯通數科針對社區沒有開源部分的設施進行了替換。聯通數科整體以 T-One 作為測試核心，基於內部搭建的 git 倉庫，建木實現任務調度和觸發，koji 實現包構建，最後由 T-One 實現測試。

—— 完 ——