如何在ci构建失败时使用SonarQube块代码？

Question

我们正在使用Jenkins建立CI管道，我们正在使用SonarQube来运行静态分析。我们已经设置了质量门，现在我们正在失败的构建，当门不满足时。当我们构建失败时，代码仍然放入sonarQube。因此，如果开发人员尝试推广两次，则第二次构建将“通过”。

实施例： 门不是新的关键问题。

开发人员检查代码中有一个新的关键问题。 构建在静态分析时失败（SonarQube标记了规则并且阻塞）。

开发人员再次检入代码（无代码更改）。 静态分析的通过是因为关键问题不是“新的”。

有没有办法在发生故障时恢复到以前的版本，或者更好的是针对最新的非故障运行运行分析？

备注：版本 - Sonarqube 5.1.2

Answer 1

您已经询问如何保持已提交的代码不会反映在SonarQube平台中。

我不建议尝试取消对已提交代码的分析，因为那时您的质量指标并未反映代码库的状态。想象一下，根据他们在SonarQube UI中看到的内容，有人正在决定HEAD是否可以发布。如果你保持“坏”代码不显示，那么...分析的重点是什么？只需使用照片编辑器构建“完美”仪表板，并在有人点击http://sonarqube.myco.com:9000时提供该gif。

好吧，这可能是一个极端的反应，但你明白我的观点。 SonarQube分析的重点是向您展示代码的正确与错误。在SonarQube UI中显示提交不应该是您通过提交“有价值”代码“获得”的荣誉。这应该是基线预期。就像遵循团队的编码惯例并使用SCM一样。

但是这个咆哮并没有解决你的问题，这就是你当前的质量门是基于last_analysis的事实。在那个时间尺度上，“新的关键问题”是一个短暂的衡量标准，而你正在失去检测新的关键问题的能力，因为它们在一分钟内是“新的”，在下一分钟是“旧的”。出于这个原因，我建议你改变你的时间表。而不是查看“新”与上次分析，与上一版本，上个月（超过30天）或去年（超过365天）进行比较。然后，您将始终能够分辨出什么是“新”与接受的基线。