LWN：对内核进行GitLab CI！

关注了就能看到更多这么棒的文章哦～

GitLab CI for the kernel

By Daroc Alden
May 17, 2024
ChatGLM translation
https://lwn.net/Articles/972713/

Linux 内核开发跟其他的很多软件项目总是有很多不同之处，而测试基础设施的去中心化就是与其他软件项目显著的区别之一。例如，syzkaller（系统调用的 fuzzer 测试），KernelCI（内核 CI 项目）或 内核自测试（kernel self tests） 等项目都在按不同的方式测试内核。2 月 28 日，Helen Koike 发布了一个补丁集，该补丁集将为整个内核添加持续集成 (CI) 脚本。该提案总体上得到了积极的回应，但一些人提出了修改建议。

Koike 的补丁集添加了一个新的顶级 ci 目录，其中包含 GitLab 持续集成功能的 YAML 配置文件，以及将这些文件与现有内核测试结合起来的 shell 脚本。它利用了她之前在内核图形子系统测试中的一些工作，这些测试也使用 GitLab 作为持续集成平台。补丁集目前包含针对提议的补丁运行 checkpatch（代码风格检查工具）和 Smatch（模块符号检查工具）的代码，并尝试在几个不同的架构上构建内核，但 Koike 计划在初始工作被接受后再继续扩大覆盖范围。补丁集还包括一个顶级 .gitlab-ci 文件，该文件指示 GitLab 默认运行测试。

补丁集本身

许多人对该提案表示了积极的回应。Tim Bird 认为该更改很有用，并表示：“我目前没有使用 GitLab，但我可能会安装它来测试一下。” Maxime Ripard 也认为这项工作可能有用，但他质疑它能多好地支持不同的用例。Ripard 指出，不同的子系统和维护者可能对持续集成的使用方式不同。“我不明白当前的架构如何 [适应] 这一点。”

Nikolai Kondrashov 指出，GitLab 可以配置为在存储库中的其他位置查找配置文件。他感觉使用顶级配置可能不是最好的选择。“这样，所有不同的子树都可以拥有完全不同的设置，但一些子树仍然可以使用 Helen 的工作并利用她实现的‘场景’。”

Linus Torvalds 同意最好不要包含顶级配置：“我一点也不想在顶级拥有一个人们会争论或更有可能忽略的东西，因为关于规则没有一个全面性的共识。” Torvalds 建议最好将 CI 项目与内核分开。

然而，Kondrashov 认为，将 CI 脚本保存在与代码相同的存储库中是有好处的。这允许开发者确保测试和代码保持同步。他建议“我们将这个贡献重新定义为一种模板，或者一种人们可以用来开始设置的参考”。他还提出了将新代码放在 ci 目录之外的可能性。

Torvalds 对将代码作为可供维护者选择使用的预制组件库的想法表示“更能接受”。他 建议 ， tools/ci 文件夹是更合乎逻辑的位置，因为它“与我们的 tools/testing 子目录类似”。Koike 同意这种方法，她说这将使她作为内核图形子系统 (DRM) 测试的维护者的工作更容易，并且仍然支持将测试覆盖范围扩展到其他子系统。她的同事 Nicolas Dufresne 后来 总结了讨论，并表示顶级配置文件将被删除。

Guenter Roeck 认为，至少有一些基本要求是所有内核开发者都可以同意的。

当然，你可以反对 checkpatch，但代码至少应该能够 构建 ，而且不应该让人们向提交者报告说构建失败。

Randy Dunlap 和 Geert Uytterhoeven 表示同意。Ripard 指出，像这样运行 CI 需要资金，并且现有测试工作（例如 DRM-CI 基础设施）的支持者可能不想为内核无关部分的测试付费。

我并不期望，比如说，clock framework 会验证所有 DRM kunit 测试是否在他们合并的每个提交中都能通过，即使其中一个可能完全破坏了一些 DRM 测试。

后续消息澄清了 Ripard 实际上是支持自动化测试，但他认为期望人们“为运行他们根本不关心的东西的编译工作付费”是不合理的。

KernelCI

Guillaume Tucker 提出了一个不同的问题：“这在 KernelCI 路线图中的地位是什么？” KernelCI 是一个项目，致力于为内核开发提供一个分布式测试自动化系统。它由 Arnd Bergmann、Olof Johansson 和 Kevin Hilman 于 2012 年启动，旨在检测内核 Arm 版本的构建失败。2019 年，它被 Linux 基金会采用，并计划扩展覆盖范围和基础设施，以满足整个内核社区的需求。

Kondrashov 回答说这项工作“是 KernelCI 项目的重要组成部分”，尽管目前不是 KernelCI 服务的一部分。该项目确实拥有现有的构建基础设施，Kondrashov 希望能够通过将 GitLab job 发送到相同的 pipeline 来进行重用。

Dufresne 建议，现有的 KernelCI 工作和新的基于 GitLab 的工具旨在服务不同的目的。KernelCI 测试主要是“集成”测试，它可以一次性地整合测试来自内核中不同地方的多个改动。Koike 提议的 GitLab 测试将在每次推送到存储库时运行，可以有效地测试单独的某个改动。根据 Dufresne 的说法，这将“有助于更早地发现提交问题，并降低 [内核] CI 回归率”。

Tucker 对这个回答并不满意，他说新代码并不局限于这种用例，并且它提供了一个“能够应对内核子系统之间工作流程多样性的平台”。Tucker 的消息还指出，代码中包含许多关于 KernelCI 的变量名称和文档，这让人混淆了这项工作究竟是否属于该项目。如果它属于该项目，Tucker 质疑为什么它跟 KernelCI 项目之前说的会提供具有新功能的全面平台的计划并不一致。

Gustavo Padovan 回答说，Tucker 忽略了一点，社区并没有真正使用 KernelCI 项目。“如果问问周围的人，就会发现社区对 KernelCI 的参与度很低。” 根据 Padovan 的说法，这项新工作是项目领导层变更后重新努力提供高质量测试的结果。他希望参与度的提高不仅会转化为更好的测试，还会带来将 KernelCI 提升到之前计划所设想的水平所需的反馈和资金。

Tucker 强调他支持新的 CI 工作，并且他只是想弄清楚它与 KernelCI 项目的关系。尽管总体反应积极，但 Koike 尚未发送补丁集的新版本。但似乎许多内核开发者都希望看到更多的自动化测试覆盖率。例如，BPF 开发者将在即将到来的 Linux 文件系统内存管理和 BPF 会议上发表关于持续集成的演讲。因此，很有可能更新版本的这项工作迟早会发布。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～