我们正在努力控制旧的遗留代码库，同时开发新功能。目前，代码编译时会出现大量编译器警告和来自静态代码分析器的警告。因此，引入新警告的代码仅仅因为新警告在洗牌中丢失而进入生产环境并不少见。
目前我们正在使用 Jenkins 进行夜间构建，并在出现新警告时使构建失败。然而，当 Jenkins 检测到新的警告时，代码已经在几个小时前合并了。因此，我们不仅要缩短反馈周期，还要确保只合并不会引入新警告的更改。
据我所知，在推送到 GitLab 时触发 Jenkins 构建是可能的。但 Jenkins 只能将警告计数与之前的构建进行比较。但我们需要与不同分支的构建进行比较。
GitLab CI 或 GitLab EE 和 Jenkins 的组合能否以某种方式配置为检测合并请求是否引入了新警告？
【问题讨论】：
标签： gitlab compiler-warnings static-analysis gitlab-ci static-code-analysis
是的，这是可能的，但这是一个开放式问题，很大程度上取决于构建需要多长时间以及您将如何比较结果。
您不必只对已签出的分支运行检查。您可以并行设置两个作业，在当前分支和开发分支上运行测试，将它们作为artifacts 传递给第三个作业并在那里进行比较。
您可能希望将构建状态存储在您的开发分支和download the artifact 到您当前的工作中，并将其与本地结果进行比较。您还可以将它们存储在数据库、文件服务器或其他任何合适的地方。
最后，您可以尝试使用像 SonarQube 这样的外部代码质量工具，它可以更深入地了解新功能和旧功能。
【讨论】：
与此同时，开发了一些工具，这些工具允许不完美但非常接近的工作流程。
Jenkins 拥有Warnings Next Generation Plugin，它可以将在一个 Jenkins 作业中发现的警告与在另一个 Jenkins 作业中发现的警告进行比较。所以我们设置了一个工作来编译我们的开发分支，每次一个新的提交被推送到它。然后，我们将结果用作基线。 GitLab 中为每个合并请求触发的另一个作业然后使用此基线来确定合并请求引入的新警告。
这很好用。
【讨论】：