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