…或者说：GTK开发者如何检查他们在工具包上的工作.
自从GNOME集体迁移到GitLab以来，GTK充分利用了该平台提供的功能，尤其是在其持续集成管道方面。
在过去，检查我们对工具包的更改是否正确的唯一方法是等待持续构建机器人通知我们在主开发分支上的任何中断。虽然这比没有好，但它不允许我们在任何开发的阶段——从功能到错误修复，从文档改进到添加新测试——防止中断。
现在，GitLab中可用的CI管道在每个分支和合并请求上运行，远早于更改到达其他所有人使用的公共开发分支。
主题分支和合并请求
当针对GTK 4主开发分支开发主题分支时，我们会运行一个CI管道，该管道从对分支中应用的更改进行简单的代码样式检查开始。样式检查使用clang-format，这通常足以满足GTK编码风格；编码风格有一些“特殊”的注意事项，clang-format可能会产生误报和漏报。因此，允许样式检查失败，但强烈建议贡献者和审阅者在出现故障时检查日志。
一旦通过样式检查，我们将运行构建阶段，该阶段目前包含三个单独的作业
- 使用Fedora容器的Linux调试构建
- Windows上的MSYS2构建
- Linux发布版本
Linux调试构建非常标准。
MSYS2构建捕获Windows上GNU工具链的任何问题。
发布版本是必要的，以确保我们不依赖于我们在开发期间使用的调试代码的副作用。
所有这些作业都运行GTK测试套件。
我们将测试报告发布为JUnit文件，利用GitLab的支持；并作为HTML报告，存储为管道工件。这使我们更容易检查哪些失败了，哪些成功了。
理想情况下，我们希望添加更多环境
- 基于其他主流发行版的Linux构建
- 使用MSVC工具链的Windows构建
- 一旦GDK后端修复，就可以进行macOS构建
在构建和测试作业通过后，我们进入分析阶段。我们在GTK的代码库上运行Clang静态分析工具并生成报告。在不久的将来，我们还可以运行诸如UBSan和ASan之类的消毒工具；用于解析器的模糊测试工具，例如GtkBuilder和CSS；或验证我们的UI定义包含适当的可访问性描述符的工具。
就像测试一样，我们将分析报告作为GitLab工件发布以供审查。
一旦分析阶段通过，我们将构建API参考，并检查结果，以确保新添加的符号得到正确记录。
最后，我们有手动CI作业来构建GTK演示应用程序的Flatpak捆绑包；窗口小部件工厂；和图标浏览器。这使设计师可以立即测试Adwaita中的更改或新添加的窗口小部件，而无需在其系统上从头开始构建GTK。
主线开发分支
一旦主题分支/合并请求的CI管道通过，我们就可以将更改合并到主开发分支中，并确信代码是正确的，并且可以执行我们想要的操作。
主开发分支运行与先前描述的相同的管道，除了Flatpak作业不再是手动的了，因此始终可以在本地测试GTK的当前前沿版本。此外，文档在在线发布，因此始终是最新的。
GTK 3呢？
在GTK 3分支中，我们有一个更简单的管道，它运行以下作业
- 在Linux和Windows/MSYS2上的完整Meson调试构建，适用于当前稳定版本的Fedora和Debian上的静态和共享库工件
- 在Linux上的完整Meson发布版本，该版本还会生成API参考
- 在Linux和Windows/MSYS2上的Autotools构建
- Linux上的可选Autotools distcheck构建
只要GTK 3支持Autotools，Autotools作业就会就位。理想情况下，我们希望利用Meson构建为macOS和Windows/MSVC添加其他作业。
一旦GTK 4 CI管道达到一定的功能和稳定性水平，我们将把它向后移植到GTK 3，以便我们更加确信当前稳定分支不会退步。
有关更多信息，您可以查看GTK存储库
.gitlab-ci.yml用于主开发分支- 包含各种帮助脚本的
.gitlab-ci目录。