Linux 内核的持续集成测试
内核 CI

> 
> CKI 团队是如何防止 bug 被合并到 Linux 内核中。
> 
> 
> 


![](/data/attachment/album/201908/02/112520aidijdddo9wwvbiv.jpg)


Linux 内核的每个发布版本包含了来自 1,700 个开发者产生的 14,000 个变更集，很显然，这使得 Linux 内核快速迭代的同时也产生了巨大的复杂性问题。内核上 Bug 有小麻烦也有大问题，有时是系统崩溃，有时是数据丢失。


随着越来越多的项目对于持续集成（CI）的呼声，[内核持续集成（CKI）](https://cki-project.org/)小组秉承着一个任务目标：防止 Bug 被合并到内核当中。


### Linux 测试问题


许多 Linux 发行版只在需要的时候对 Linux 内核进行测试。而这种测试往往只在版本发布时或者用户发现错误时进行。


有时候，出现玄学问题时，维护人员需要在包含了数万个补丁的变更中匆忙地寻找哪个补丁导致这个新的玄学 Bug。诊断 Bug 需要专业的硬件设备、一系列的触发器以及内核相关的专业知识。


#### CI 和 Linux


许多现代软件代码库都采用某种自动化 CI 测试机制，能够在提交进入代码存储库之前对其进行测试。这种自动化测试使得维护人员可以通过查看 CI 测试报告来发现软件质量问题以及大多数的错误。一些简单的项目，比如某个 Python 库，附带的大量工具使得整个检查过程更简单。


在任何测试之前都需要配置和编译 Linux。而这么做将耗费大量的时间和计算资源。此外，Linux 内核必需在虚拟机或者裸机上启动才能进行测试。而访问某些硬件架构需要额外的开销或者非常慢的仿真。因此，人们必须确定一组能够触发错误或者验证修复的测试集。


#### CKI 团队如何运作？


Red Hat 公司的 CKI 团队当前正追踪来自数个内部内核分支和上游的[稳定内核分支树](https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html)等内核分支的更改。我们关注每个代码库的两类关键事件：


1. 当维护人员合并 PR 或者补丁时，代码库变化后的最终结果。
2. 当开发人员通过拼凑或者稳定补丁队列发起变更合并时。


当这些事件发生时，自动化工具开始执行，[GitLab CI 管道](https://docs.gitlab.com/ee/ci/pipelines.html)开始进行测试。一旦管道开始执行 [linting](https://en.wikipedia.org/wiki/Lint_(software)) 脚本、合并每一个补丁，并为多种硬件架构编译内核，真正的测试便开始了。我们会在六分钟内完成四种硬件架构的内核编译工作，并且通常会在两个小时或更短的时间内将反馈提交到稳定邮件列表中。（自 2019 年 1 月起）每月执行超过 100,000 次内核测试，并完成了超过 11,000 个 GitLab 管道。


每个内核都会在本地硬件架构上启动，其中包含：


* [aarch64](https://en.wikipedia.org/wiki/ARM_architecture)：64 位 [ARM](https://www.arm.com/)，例如 [Cavium（当前是 Marvell）ThunderX](https://www.marvell.com/server-processors/thunderx-arm-processors/)。
* [ppc64/ppc64le](https://en.wikipedia.org/wiki/Ppc64)：大端和小端的 [IBM POWER](https://www.ibm.com/it-infrastructure/power) 系统。
* [s390x](https://en.wikipedia.org/wiki/Linux_on_z_Systems)：[IBM Zseries](https://www.ibm.com/it-infrastructure/z) 大型机
* [x86\_64](https://en.wikipedia.org/wiki/X86-64)：[Intel](https://www.intel.com/) 和 [AMD](https://www.amd.com/) 工作站、笔记本和服务器。


这些内核上运行了包括 [Linux 测试项目（LTP）](https://github.com/linux-test-project/ltp)在内的多个测试，其中包括使用常用测试工具的大量测试。我们 CKI 团队开源了超过 44 个测试并将继续开源更多测试。


### 参与其中


上游的内核测试工作日渐增多。包括 [Google](https://www.google.com/)、Intel、[Linaro](https://www.linaro.org/) 和 [Sony](https://www.sony.com/) 在内的许多公司为各种内核提供了测试输出。每一项工作都专注于为上游内核以及每个公司的客户群带来价值。


如果你或者你的公司想要参与这一工作，请参加在 9 月份在葡萄牙里斯本举办的 [Linux Plumbers Conference 2019](https://www.linuxplumbersconf.org/)。在会议结束后的两天加入我们的 Kernel CI hackfest 活动，并推动快速内核测试的发展。


更多详细信息，[请见](https://docs.google.com/presentation/d/1T0JaRA0wtDU0aTWTyASwwy_ugtzjUcw_ZDmC5KFzw-A/edit?usp=sharing)我在 Texas Linux Fest 2019 上的演讲。




---


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


作者：[Major Hayden](https://opensource.com/users/mhayden) 选题：[lujun9972](https://github.com/lujun9972) 译者：[LazyWolfLin](https://github.com/LazyWolfLin) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
With 14,000 changesets per release from over 1,700 different developers, it's clear that the Linux kernel moves quickly, and brings plenty of complexity. Kernel bugs range from small annoyances to larger problems, such as system crashes and data loss.

As the call for continuous integration (CI) grows for more and more projects, the [Continuous Kernel Integration (CKI)](https://cki-project.org/) team forges ahead with a single mission: prevent bugs from being merged into the kernel.

## Linux testing problems

Many Linux distributions test the Linux kernel when needed. This testing often occurs around release time, or when users find a bug.

Unrelated issues sometimes appear, and maintainers scramble to find which patch in a changeset full of tens of thousands of patches caused the new, unrelated bug. Diagnosing the bug may require specialized hardware, a series of triggers, and specialized knowledge of that portion of the kernel.

### CI and Linux

Most modern software repositories have some sort of automated CI testing that tests commits before they find their way into the repository. This automated testing allows the maintainers to find software quality issues, along with most bugs, by reviewing the CI report. Simpler projects, such as a Python library, come with tons of tools to make this process easier.

Linux must be configured and compiled prior to any testing. Doing so takes time and compute resources. In addition, that kernel must boot in a virtual machine or on a bare metal machine for testing. Getting access to certain system architectures requires additional expense or very slow emulation. From there, someone must identify a set of tests which trigger the bug or verify the fix.

### How the CKI team works

The CKI team at Red Hat currently follows changes from several internal kernels, as well as upstream kernels such as the [stable kernel tree](https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html). We watch for two critical events in each repository:

-
When maintainers merge pull requests or patches, and the resulting commits in the repository change.

-
When developers propose changes for merging via patchwork or the stable patch queue.


As these events occur, automation springs into action and [GitLab CI pipelines](https://docs.gitlab.com/ee/ci/pipelines.html) begin the testing process. Once the pipeline runs [linting](https://en.wikipedia.org/wiki/Lint_(software)) scripts, merges any patches, and compiles the kernel for multiple architectures, the real testing begins. We compile kernels in under six minutes for four architectures and submit feedback to the stable mailing list usually in two hours or less. Over 100,000 kernel tests run each month and over 11,000 GitLab pipelines have completed (since January 2019).

Each kernel is booted on its native architecture, which includes:

● [aarch64](https://en.wikipedia.org/wiki/ARM_architecture): 64-bit [ARM](https://www.arm.com/), such as the [Cavium (now Marvell) ThunderX](https://www.marvell.com/server-processors/thunderx-arm-processors/).

● [ppc64/ppc64le](https://en.wikipedia.org/wiki/Ppc64): Big and little endian [IBM POWER](https://www.ibm.com/it-infrastructure/power) systems.

● [s390x](https://en.wikipedia.org/wiki/Linux_on_z_Systems): [IBM Zseries](https://www.ibm.com/it-infrastructure/z) mainframes.

● [x86_64](https://en.wikipedia.org/wiki/X86-64): [Intel](https://www.intel.com/) and [AMD](https://www.amd.com/) workstations, laptops, and servers.

Multiple tests run on these kernels, including the [Linux Test Project (LTP)](https://github.com/linux-test-project/ltp), which contains a myriad of tests using a common test harness. My CKI team open-sourced over 44 tests with more on the way.

## Get involved

The upstream kernel testing effort grows day-by-day. Many companies provide test output for various kernels, including [Google](https://www.google.com/), Intel, [Linaro](https://www.linaro.org/), and [Sony](https://www.sony.com/). Each effort is focused on bringing value to the upstream kernel as well as each company’s customer base.

If you or your company want to join the effort, please come to the [Linux Plumbers Conference 2019](https://www.linuxplumbersconf.org/) in Lisbon, Portugal. Join us at the Kernel CI hackfest during the two days after the conference, and drive the future of rapid kernel testing.

For more details, [review the slides](https://docs.google.com/presentation/d/1T0JaRA0wtDU0aTWTyASwwy_ugtzjUcw_ZDmC5KFzw-A/edit?usp=sharing) from my Texas Linux Fest 2019 talk.

## Comments are closed.