我最近融入sonarqube
了我们的发布过程。我已将泄漏期设置为整合日期,并在quality gate
定义中规定自泄漏期开始以来应该有零个新问题。
问题是每当文件发生更改时,sonarqube 就会开始将所有以前的问题视为新问题。这对于大文件尤其成问题,因为对文件进行任何更改的人需要回顾性地进行所有更正。我想要 sonarqube 做的是从责任信息中兑现提交日期,并new
通过将提交日期与泄漏期进行比较来定义。
如何使这成为可能?我在用sonarqube 6.0
我最近融入sonarqube
了我们的发布过程。我已将泄漏期设置为整合日期,并在quality gate
定义中规定自泄漏期开始以来应该有零个新问题。
问题是每当文件发生更改时,sonarqube 就会开始将所有以前的问题视为新问题。这对于大文件尤其成问题,因为对文件进行任何更改的人需要回顾性地进行所有更正。我想要 sonarqube 做的是从责任信息中兑现提交日期,并new
通过将提交日期与泄漏期进行比较来定义。
如何使这成为可能?我在用sonarqube 6.0
您的用例是SonarQube 泄漏概念的核心。您需要做的就是确保有一个与泄漏期开始相对应的分析,并将根据当时已经存在的问题设置基线。执行此操作的正确方法是实际使用sonar.projectDate(请参阅分析参数)进行初始分析。底线:
SonarQube 使用FYI SCM责备信息来自动分配问题和识别新代码上的覆盖率,但是它不能可靠地确定哪些问题是新的或不是:想象一个在您的代码中定义和使用的变量,如果提交删除它的使用然后它会在变量定义上引发一个变量未使用的问题,而该精确的行没有被任何提交触及。这就是为什么问题相对于 SonarQube 首次检测到它们的日期(在之前的分析中)被确定为新问题,因此上面详述了工作流程。