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

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

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

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

图片来源：

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

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

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

查看英文原文：