Linux 内核的持续集成测试

Linux 内核每个版本都有超过 1,700 位不同的开发者提交的 14,000 个变更集，显然 Linux 内核发展迅速且非常复杂。内核错误从小问题到系统崩溃和数据丢失等大问题不等。

随着越来越多的项目呼吁持续集成 (CI)，持续内核集成 (CKI) 团队正朝着一个单一使命迈进：防止错误合并到内核中。

Linux 测试问题

许多 Linux 发行版在需要时测试 Linux 内核。这种测试通常发生在发布时，或当用户发现错误时。

有时会出现不相关的问题，维护人员争先恐后地在包含数万个补丁的变更集中找到哪个补丁导致了新的、不相关的错误。诊断错误可能需要专用硬件、一系列触发器以及对内核该部分的专门知识。

CI 和 Linux

大多数现代软件仓库都有某种自动化 CI 测试，在提交代码进入仓库之前对其进行测试。这种自动化测试使维护人员能够通过查看 CI 报告来发现软件质量问题以及大多数错误。较简单的项目（例如 Python 库）附带大量工具，使此过程更加容易。

Linux 必须在任何测试之前进行配置和编译。这样做需要时间和计算资源。此外，该内核必须在虚拟机或裸机机器上启动才能进行测试。访问某些系统架构需要额外的费用或非常缓慢的模拟。从那里，必须有人确定一组触发错误的测试或验证修复程序。

CKI 团队如何工作

Red Hat 的 CKI 团队目前跟踪来自多个内部内核以及上游内核（例如 稳定内核树）的更改。我们关注每个仓库中的两个关键事件

1. 当维护人员合并拉取请求或补丁，以及仓库中由此产生的提交发生更改时。

2. 当开发人员通过 patchwork 或稳定补丁队列提议合并更改时。

当这些事件发生时，自动化会立即启动，GitLab CI 管道开始测试过程。一旦管道运行 linting 脚本，合并任何补丁，并为多个架构编译内核，真正的测试就开始了。我们可以在六分钟内为四个架构编译内核，并在通常两小时或更短的时间内将反馈提交到稳定邮件列表。每月运行超过 100,000 个内核测试，并且已完成超过 11,000 个 GitLab 管道（自 2019 年 1 月起）。

每个内核都在其原生架构上启动，包括

● aarch64：64 位 ARM，例如 Cavium（现为 Marvell）ThunderX。

● ppc64/ppc64le：大端和小端 IBM POWER 系统。

● s390x：IBM Zseries 大型机。

● x86_64：英特尔和 AMD 工作站、笔记本电脑和服务器。

多个测试在这些内核上运行，包括 Linux 测试项目 (LTP)，其中包含使用通用测试工具包的大量测试。我的 CKI 团队开源了超过 44 个测试，并且还有更多测试正在开发中。

参与进来

上游内核测试工作日渐壮大。许多公司为各种内核提供测试输出，包括 Google、英特尔、Linaro 和 Sony。每项工作的重点都是为上游内核以及每家公司的客户群带来价值。

如果您或您的公司想加入这项工作，请参加在葡萄牙里斯本举行的 2019 年 Linux Plumbers 大会。在会议结束后的两天内加入我们的 Kernel CI hackfest，共同推动快速内核测试的未来。

有关更多详细信息，请查看我在 2019 年德克萨斯 Linux Fest 演讲的幻灯片。