……或者：GTK 开发人员如何检查他们在工具包上的工作.
自从 GNOME 集体迁移到 GitLab 以来，GTK 已经利用了该平台提供的功能，尤其是在其持续集成管道方面。
在过去，检查我们对工具包的更改是否正确的唯一方法是等待 Continuous 构建机器人通知我们在主开发分支上是否有任何损坏。虽然这总比没有好，但它不允许我们在任何开发阶段——从功能到错误修复，从文档改进到添加新测试——期间阻止损坏。
现在，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目录，其中包含各种辅助脚本。