我最近在我们的发布过程中集成了 sonarqube。我已将泄漏期设置为集成日期，并在质量门定义中强制要求自泄漏期开始以来新问题应该为零。
问题是每当文件发生更改时，sonarqube 就会开始将所有以前的问题视为新问题。对于大文件来说，这尤其成问题，因为对文件进行任何更改的人都需要回顾性地进行所有更正。我希望 sonarqube 做的是尊重责任信息中的提交日期，并通过将提交日期与泄漏周期进行比较来定义新的。
如何使这成为可能？我正在使用 sonarqube 6.0
最佳答案
您的用例是 SonarQube Leak Concept 的核心。您需要做的就是确保有一个与泄漏期开始相对应的分析，并将根据当时已经存在的问题设定基线。正确的方法是实际使用 sonar.projectDate (请参阅 Analysis Parameters )进行初始分析。底线:
- 查看与您的案例中的集成相对应的提交
- 通过将 sonar.projectDate 设置为提交日期和 sonar.projectVersion 设置为基线来分析它，例如
- 将泄漏期设置为基线
- 对于所有进一步的分析，泄漏将对应于自初始基线以来引入的新问题。遗留问题(集成之前)将被视为遗留问题，不会计入泄漏期，然后您的质量门就可以按照您的预期完成工作。
仅供引用 SCM 责备信息由 SonarQube 用于自动分配问题并识别新代码的覆盖范围，但是它无法可靠地确定哪些问题是新与否:想象一下在代码中定义和使用的变量，如果提交删除了它的使用，那么它将在变量定义上引发变量未使用问题，而该精确行没有被任何修改犯罪。这就是为什么相对于 SonarQube 首次检测到问题的日期(在之前的分析期间)，问题被确定为新问题的原因，因此是上面详细介绍的工作流程。
关于java - Sonarqube 在计算新错误/漏洞/泄漏时不尊重 git 提交日期，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39738601/