技术问题

SonarQube Webhook的配置，和推送失败时的排查，重点并不只是填进去一个回调地址就完成了，而是要去确认这个地址，能够被SonarQube的服务器正常访问到，并且接收的那一端，也能够正确地识别出推送过来的内容。Webhook这个东西，通常是用来把扫描完成、质量门禁的状态这一类结果，推送给Jenkins、GitLab、企业微信、钉钉，或者是公司内部的平台。SonarQube它支持项目这一级，和全局这一级的Webhook配置，项目级的，是可以在项目的设置里面去配，全局级的，则是可以在系统的管理里面去配。

SonarQube新代码周期的设置，以及新代码周期对门禁结果的影响，是很多团队在配置质量门禁时容易忽略的问题。新代码周期并不是一个单纯的日期设置，它决定了哪些代码会被SonarQube当作“新增或修改的代码”来评估。如果质量门禁主要看的是新代码指标，那么新代码周期的设置一旦不同，同一份代码的门禁结果，也就可能会跟着不同。在SonarQube里面，新代码的定义可以按照全局、项目，或者是分支的层级来进行配置，而且它会影响到新代码问题，以及相关质量指标的计算。

SonarQube安全热点的审查，以及安全热点状态的同步，是安全扫描被接入研发流程以后，经常会碰到的问题。安全热点并不是已经被确认的漏洞，它是在提示这一段代码涉及到了安全方面比较敏感的逻辑，需要由开发人员，或者是安全人员，去进一步做出判断。在SonarQube的文档里面，也明确地把安全热点和漏洞区分了开来：安全热点需要经过人工的审查以后，再去判断是不是要进行修复；而漏洞通常代表的是已经影响到应用安全，应当被优先去修复的问题。所以，在处理安全热点的时候，不能只是看它的数量有多少，也不能简单地就把它一键关掉。

SonarQube项目权限的设置，和因为权限问题导致成员看不到代码的处理，需要先分清楚项目到底是Public还是Private。公开的项目，一般来说更容易被访问到，私有的项目，则需要明确地去给用户，或者用户组进行授权。在SonarQube的官方说明里面，私有项目是需要去配置Browse Project和See Source Code这些权限的；如果要查看项目的结构和代码，私有项目的用户，就需要同时具备Browse和See Source Code这两项权限。

在SonarQube里，项目权限这件事最容易被理解错的地方，不是按钮在哪里，而是“继承”到底指什么。按官方口径，项目创建时会先套用一套Permission Template，也就是模板默认权限；但模板套上去以后，项目和模板之间并不存在持续联动关系，后面你手工改项目权限、或者再去改模板，本来就不会自动互相跟着变。再加上SonarQube的项目权限本身又不是累加关系，所以很多人看到“模板明明给了权限，项目里却不对”，本质上往往是把“初始化套用”误当成了“持续继承”。

很多团队把SonarQube接进流水线以后，主干分析通常很快就能跑起来，但一到分支分析，问题就会集中在两处。一处是不确定分支到底怎么建出来，另一处是不知道分支结果和主干该按什么口径去比。按SonarSource当前官方文档，分支分析从Developer Edition起才提供，分支是在分析时传入sonar.branch.name后创建出来的；而分支和主干的对比，本质上又不是靠手工看两份报告，而是靠Reference branch也就是参考分支，配合New Code口径去做差异判断。把这两层先分清，后面配置和看结果都会顺很多。