Intel 图形库 Mesa 的持续集成

Mesa CI 是 Intel 的一个持续集成系统，用于运行 Mesa 图形库的构建和一致性测试套件。它运行在 200 多个系统中，每天运行数千万次测试。

Mesa 项目是 OpenGL 和 Vulkan 等图形标准的 OSS 实现。Intel 和 AMD 将其作为图形驱动程序的基础。它充当图形 API 和硬件驱动程序之间的转换层。Mesa 开发人员使用一个名为 Mesa CI 的框架进行持续集成，特别是在他们的测试套件中。Mesa 需要支持各种供应商图形驱动程序以及不同版本的API 标准。这就需要一个全面的测试套件，它需要与每个提交一起运行，以确保功能和性能。 Piglit 、 dEQP 、 VK-GL-CTS 和 Crucibleare 是一些在 Mesa CI 上运行的测试套件。在最近的 X Org 开发者大会上， Mark Janes 和 Clayton Craft 分享了一些关于 Mesa CI 的细节。

Mesa CI 包括一组配置文件和一个可以在 Jenkins 上运行的作业调度器及作业实现。它主要是用 Python 编写的，其原则是“把最小化 Jenkins 中的配置作为 Mesa CI 最重要的设计考虑”。根据文档，Mesa CI 理论上可以运行在任何 CI 基础设施之上，而不仅仅是 Jenkins。目前，它被用于开发测试、发布验证、Intel 驱动程序模拟器的投产前（硬件）测试、性能测试和一致性测试套件的验证。典型的开发测试周转时间是 30 分钟，即使向主分支的一次提交触发了数百万个测试。自定义数据库提供对测试历史的即时访问，系统还为公共基准测试生成性能趋势线。

Mesa CI 创建于 2014 年，但人们认识到 Mesa 自动化测试的好处比这要早。从那时起，发布过程就正规化了，并且一直在发展（PDF）。在之前的一篇文章（PDF）中，Janes 分享了为 Mesa 建立持续集成的理念。将测试作为一等工件，其中包括对测试可靠性和运行时间进行优先级排序。

图片来源： https://xdc2018.x.org/slides/Mesa_Continuous_Integration_at_Intel.pdf

每个平台都有一个单独的 CI 配置文件，一些测试套件需要一个单独的配置用于 32 位构建。由提交引起的测试失败会触发一系列步骤，其中一些是手动的。失败的测试被添加到 CI 配置的跳过列表中。不过，这并不是由开发人员完成的，也不知道这是否是因为测试框架没有注解测试用例而导致它们被忽略了。 JUnit 和 NUnit 等常见测试套件都提供了这个特性。跳过列表中的测试仍然运行，但失败时不会报告。这可以避免在 Bug 修复之前损失测试覆盖率。

当在包含未修复的 Bug 的分支上开发特性时，由于 CI 配置会跟踪主分支，所以会导致构建失败。对于每个测试状态更改，Mesa CI 都会记录导致这种情况的提交。在这种情况下，由于 Bug 修复会被推送到主分支，所以当测试开始通过时，它会记录提交 id。Mesa CI 会检查特性分支是否已经修复。如果没有，它就认为测试状态是错误的，即预计测试会失败。最终，旧的稳定分支会在 Mesa CI 上运行，因为它们具有与该分支上的源代码一致的测试状态 CI 配置。但是，对于旧的分支，测试仍然会失败，测试机器上有硬件更新，而这些更新会影响所有分支。

Mesa CI 的未来计划包括在构建执行期间显示日志和组件的状态，并允许开发人员对构建进行 A/B 比较。他们还可以使用公共仪表板。

查看英文原文： Continuous Integration at Intel for the Mesa Graphics Library