对不起，增量覆盖率门禁我们原生支持了

在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

祝你玩得愉快。