...或者说：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目录，包含各种辅助脚本。