SonarQube

提交拉取请求后，流水线已经跑完，页面却没有SonarQube检查结果，这时要先分清两件事：分析有没有完成，结果有没有传回代码仓库。两处使用的配置和凭据并不相同。下面以SonarQube Server与GitHub Actions为例，说明配置过程和排查入口；菜单参照Server 10.8等版本，其他版本可按对应名称查找。

在软件质量管理过程中，SonarQube质量规则用于约束代码检查标准，帮助开发团队发现潜在问题。实际使用SonarQube时，质量规则配置并不是一次完成后长期不变，随着项目语言、编码规范以及团队要求变化，经常需要调整规则内容。部分用户在修改规则后会发现扫描结果没有变化，甚至新规则没有参与检查，这类问题通常和规则激活状态、质量配置、项目绑定关系以及扫描缓存有关。因此，配置SonarQube质量规则时，需要确认规则应用范围，并在修改后检查对应项目是否真正加载了新的配置。

一套SonarQube环境通常会接入多个代码仓库。项目名称可以相似，但项目密钥必须能够准确区分每个项目。密钥重复、大小写不一致，或者扫描任务读取了错误配置，都可能让结果进入其他项目，甚至直接中断分析。了解SonarQube项目密钥怎么设置SonarQube项目密钥冲突导致分析失败怎么办，可以帮助团队把网页项目、代码仓库和流水线配置对应起来。

SonarQube分支分析怎么开启，还有分支分析出来的结果为什么跟主分支对不上，这些是不少团队在把扫描接入CI之后都会碰到的问题。分支分析这件事，不是说把不同的分支挨个扫一遍再统统塞进同一个项目就行了的，它需要版本那边能支持、扫描时传的参数得对、代码基线要定好，还有对新代码的定义也要一起配合着来才行。另外有一件事得先弄清楚：SonarQube Server的分支分析功能是从Developer Edition才开始提供的，Community Edition一般只保留单个项目的分支视图，所以在动手之前得先确认好版本。

在给新项目接入扫描、迁移流水线、调整账号权限，还有令牌到期了以后，常常会碰到一类问题，那就是SonarQube的扫描令牌，到底应该怎么去配置它，还有，一旦那个令牌失效了，为什么项目就没法再继续分析了，SonarQube的扫描令牌，它可不是一串普普通通的字符串，这个东西，代表的是某一个用户，或者是某一个项目，它所拥有的分析权限，按照官方文档的说明，令牌是可以被拿来执行分析用的，用的时候，不需要把真实的账号密码给暴露出去；但是呢，在跑分析的时候，那个令牌所对应的用户，他必须得拥有，对这个项目的执行分析的权限。

在软件质量检测过程中，代码覆盖率可以帮助开发人员了解测试代码对项目源码的覆盖情况。使用SonarQube查看覆盖率时，很多问题并不来自SonarQube本身，而是测试工具生成的覆盖率文件没有正确传递，或者项目扫描配置存在遗漏。例如测试没有执行、报告文件路径错误、扫描参数未配置等情况，都可能导致覆盖率页面没有数据显示。因此，在设置SonarQube代码覆盖率时，需要先完成测试覆盖率采集，再将生成的数据交给SonarQube分析。

SonarQube的Pull Request分析用于检查本次代码变更引入的新问题，并把质量门结果与代码评审流程结合起来。它和普通分支分析并不是同一种任务：Pull Request分析需要明确源分支、目标分支以及PR标识，同时依赖CI流水线触发。处理“SonarQube怎么配置Pull Request分析，SonarQube Pull Request分析结果不显示如何排查”时，应先确认分析任务确实被识别为Pull Request，再判断问题出在扫描提交、后台处理还是DevOps平台展示环节。

团队使用SonarQube一段时间后，往往会根据项目语言、代码规范和风险要求调整检测规则。规则数量一多，如果仍直接修改默认配置，后续很难分清哪些规则被启用、哪些参数被改过。遇到扫描结果没有变化时，也容易把问题误认为扫描器失效。弄清SonarQube规则配置文件怎么管理SonarQube规则调整后扫描结果为什么不变，可以让规则维护、项目绑定和扫描验证形成一套清楚的流程。

在SonarQube里，误报这回事到底要怎么去处理，还有已经给它标上了误报之后，审查的记录又该怎么留下来，不能简单地理解成“工具报了，可我觉得没事，点掉就算了”。SonarQube里面可以把问题标成False positive或是Accepted，False positive更对路的用法，是分析出来的结果确实弄错了，Accepted就更偏着“问题是有的，但现在先这么接受，后面再找时间弄”。这两个状态要是混着用，后面做质量审查的时候，就不容易说清楚了。

在一条流水线被长期接入之后，经常会出现一类问题，就是SonarQube里面的历史分析记录，该怎么样去清理一下，还有它的数据库体积，要是变得太大了，又该怎么去处理，项目每天都在那跑扫描、分支被反反复复地创建、版本号也在不停地变化，这么一来，数据库就会慢慢地变大，SonarQube它自己，其实是有一套后台维护机制的，它会在新的分析被执行完了以后，去清理掉一部分旧的数据、旧的历史快照、PR的分析，还有分支的记录，靠着这个，来减缓数据库的膨胀，官方的文档里也说明了，那些旧的分析，是不会被完完整整地一直保留着的，不然的话，数据库就会变得臃肿不堪。

在软件开发过程中，代码安全检查已经成为质量管理中的重要环节。使用SonarQube分析代码漏洞时，可以帮助开发人员发现潜在安全问题，例如不安全的数据处理方式、风险函数调用以及代码逻辑缺陷。实际使用过程中，有些项目扫描完成后发现漏洞数量明显少于预期，或者部分已知问题没有出现在报告中。这类情况通常和扫描配置、规则启用状态、代码范围以及分析过程有关。因此，进行漏洞扫描时，需要先确认分析环境，再结合扫描结果检查可能遗漏的位置。

SonarQube中的技术债务用于估算维护性问题的修复工作量，并通过技术债务比率和可维护性评级反映代码维护压力。进行“SonarQube怎么查看技术债务，SonarQube技术债务评估结果怎么看”时，不能只看总时长，还要结合具体问题、新代码范围和评级判断，避免把预计修复工作量直接等同于实际工期。

SonarQube令牌怎么生成SonarQube令牌失效后构建任务怎么处理，这主要取决于令牌是用于个人本地扫描，还是挂在CI/CD构建任务中。按照SonarQube官方的解释，用户令牌能够用来做代码分析，在扫描时可以当作sonar.token参数传入，也可以搁在SONAR_TOKEN环境变量里；令牌一旦到了期限，就没办法再接着用了。

SonarQube里质量门禁要怎么去设，还有当这个门禁过不去的时候，应该先查哪些指标，很多团队把静态代码检查接进CI以后，都会撞上这个问题。质量门禁这个东西，它不单单是去看一下代码扫描成没成功，而是用事先定好的一组条件，去判断这回交上来的代码，到底够不够格合进去，或者能不能往外面发。它主要是拿来卡新代码的，也可以去卡整体代码，现在搞项目的人一般都会说，先把力气用在管好新代码上头，这么一来，就不会弄成老问题还没清掉，新问题又跟着跑进来的局面。

在企业想要统一账号体系的时候，有两件事是需要处理的，一件是怎么把SonarQube接入到LDAP的登录里去，另一件是用户和组的映射关系，又要怎么去配置好，SonarQube是可以把认证这件事，委托给LDAP或者是Active Directory去做的，当一个用户第一次登录成功了以后，SonarQube里面就会自动地给他建好一个账号，等到后面他再登录的时候，也都会去同步他的用户名、邮箱，还有一些可以选择的组的关系，按照官方文档给出的说明，去接入LDAP这件事，主要是靠在安装目录下面，去修改conf文件夹里面的配置文件来完成的，等改完了以后再去重启一下服务，然后通过看日志，来确认跟LDAP的连接是不是真的通了。

测试文件显示为未覆盖时，先检查文件分类。即使测试执行成功，错误分类也会影响覆盖率。围绕“SonarQube怎么区分源码目录和测试目录，SonarQube测试文件被计入覆盖率分母如何调整”，下面以SonarQube Server英文界面及JavaScript、TypeScript项目的SonarScanner CLI配置为例说明。

SonarQube项目中常会混入生成代码、第三方源码、测试资源和临时文件，但这些内容并不一定都需要参与同一种分析。处理“SonarQube怎么设置文件排除规则，SonarQube排除规则不生效如何检查”时，第一步不是直接写通配符，而是先确定究竟要【完全排除文件】、【排除覆盖率统计】还是【排除重复代码检测】。不同目标对应不同参数，配置位置、路径基准和CI中的覆盖参数也会影响最终结果。

项目多次迭代后，相似的校验、转换、异常处理和接口调用可能分散在不同文件中。代码虽然还能运行，但后续修改同一条规则时，开发人员往往要同时处理多个位置，漏改一处就可能造成逻辑不一致。弄清SonarQube重复代码怎么查看SonarQube重复代码比例过高怎么降低，可以先找到重复集中的文件，再根据业务关系完成重构和验证。

SonarQube覆盖率报告怎么导入SonarQube覆盖率数据显示为空怎么办，很多团队在把代码质量平台搭起来以后，都会撞上这个问题。SonarQube这个工具自己是不会去生成覆盖率报告的，那串数据得先让JaCoCo、LCOV、coverage.py、dotnet-coverage或者gcov这类外部的测试覆盖率工具给跑出来，然后扫描器在分析的那一步，再把它们读到SonarQube里头，最后才在页面上亮出来。说白了，SonarQube干的活儿是接住这些数据然后展示出来，它可不替你跑测试，也不替你往外头吐覆盖率文件。

在SonarQube里面，扫描项目要怎么去配置，还有扫描的时候那些参数要是漏掉了、没给填上，会对最后出来的结果带来什么样的影响，这一块主要还是得去看项目用的是哪一种构建的方式，还有扫出来的结果要不要把分支、覆盖率，还有质量门禁这些个东西都给接进来。在SonarQube里头，那些拿来分析用的参数，一般都是照着sonar.<property>这么一种样子去写的，有一部分参数，是能够在项目里面给写到一个配置文件里面去的，也可以通过命令行的方式，或者在CI的脚本里面，把它给传进去。