在SonarQube 8之后,官方提供了专门的针对 Pull Request的代码扫描方式,再结合质量门禁中的增量代码(new code)覆盖率指标,可以说是原生支持增量代码覆盖率的诉求了,如下图所示,
案例中针对新增的15行代码,计算出了92.6%的增量覆盖率和83.6的全量覆盖率(合并之后)。
配合上述功能,团队只要在Gitlab/GitHub中使用Merge Request/Pull Request 来 工作,确保只使用MR/PR的方式向主干分支上提交代码,而不再使用Push方式,就能保障所有发布到线上的代码都是通过了质量门禁要求的。
这样的玩法就比较吸引人了,不过有个问题就是,
Pull Request analysis is available starting in Developer Edition.
上述功能主要是通过SonarQube的分支插件来实现的,因此只要引入了开源社区提供的SonarQube 分支插件,就能实现这一过程了。具体的插件配置和使用过程,可以参见《Gitlab+Jenkins+SonarQube计算增量覆盖率》。
当然,还需要更新一下sonar scanner在扫描时的玩法。从原来指定分支的方式修改成为指定pullrquest。
原先方案:
Mvn sonar:sonar -Dsonar.branch.name=ref/merge_reqeust/201 -Dsonar.branch.target=develop
修改为:
Mvn sonar:sonar -Dsonar.pullrequest.key=201 -Dsonar.pullrequest.branch=feature-jira223 -Dsonar.pullrequest.base=develop
以下是这三个参数的含义:
Description
可以参考 https://docs.sonarqube.org/latest/analysis/pull-request/ 了解更多。
需要强调的是,在设置sonar scanner 扫描时,不能有任何关于 sonar.branch.*的参数,否则scanner就认为是在处理某个分支的扫描,而不是针对pull request类的扫描。
那么,接下来的问题是如何配合CI环境来实现自动化的过程了。以Jenkins为例,可以参考gitlab-plugin
https://github.com/jenkinsci/gitlab-plugin#defined-variables
这个插件符合接收Gitlab在MR时发出的webhook并进行解析,提供了一系列后续可以使用的变量。如本例中,则可以在构建脚本中直接使用以下的三个变量,
gitlabSourceBranch
gitlabMergeRequestId
gitlabTargetBranch
祝你玩得愉快。