技术问题

SonarScanner显示EXECUTION SUCCESS，项目页面却迟迟没有新结果，这种情况并不少见。扫描器只是把分析报告上传到服务器，后续还要交给Compute Engine处理。后台任务没跑完，结果就不会正式进入项目。

SonarQube里的“质量配置”通常指Quality Profile，它决定某种编程语言启用哪些检查规则。团队想给新项目沿用现有标准时，复制一份很方便。麻烦也常出在这里。明明从同一个配置复制，过一段时间再看，规则数量却对不上。遇到这种情况，别急着一条条手工补，先确认用的是复制、继承，还是跨服务器导入。

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这两项权限。