在SonarQube里面，扫描项目要怎么去配置，还有扫描的时候那些参数要是漏掉了、没给填上，会对最后出来的结果带来什么样的影响，这一块主要还是得去看项目用的是哪一种构建的方式，还有扫出来的结果要不要把分支、覆盖率，还有质量门禁这些个东西都给接进来。在SonarQube里头，那些拿来分析用的参数，一般都是照着sonar.
一、SonarQube扫描项目要怎么去配置
拿SonarQube去扫一个项目，它可不是光跑完一条命令就能了事的。要把事情做得稳当一些的话，通常的做法是先去把项目它到底是什么身份、源码的范围给圈出来、认证那边要用的信息，还有构建的环境，都一一给弄清楚，然后再去动手执行那个扫描。要是参数那一块设得不明不白的，扫描有时候倒是能给你跑完，可它吐出来的结果，那就不一定靠得住了。
1、先把项目的基础信息给配好
在【sonar.projectKey】、【sonar.projectName】还有【sonar.sources】这几个东西里面，去把项目它用来做标记的那个标识、项目的名字，还有放着源码的目录，都给确认清楚。
sonar.projectKey这个东西，它是被拿来区分不同的项目的，可不能随随便便就让它给重复了；sonar.sources呢，它会去决定，到底有哪些目录是要被纳进扫描的范围里头来的。源码目录要是给它填得太大了，就会连带着把那些不相干的代码，也给一块儿扫了进来；可要是填得太小了，那些核心的模块，又很有可能会被漏掉。那个SonarScanner CLI这个工具，它是支持去一个叫sonar-project.properties的文件里面，把配置给读出来的，同时，也可以靠着命令行里头带上-D那样的参数，给它传进去。
2、接下来，再去把服务器跟认证的东西给配好
在做扫描的时候，还要去确认一下【sonar.host.url】和【sonar.token】这俩东西，填得到底对不对。sonar.host.url这个参数，它指向的是SonarQube服务器的那个地址，而sonar.token呢，就是拿来在扫描的时候做认证用的。
Token它所对上的那个用户，是需要手里头握着去执行分析的权限的，要是没有的话，那扫描就有可能在往上传结果，或者是在认证的那个阶段，直接就失败了。一个新项目在往CI流水线里面去接的时候，这两个参数是最容易被放错位置的，就比如说，在本地机器上扫得好好的，可一到了流水线里面，它就连不上服务器了。
3、照着你那个项目的类型，去挑一个合适的扫描器
那种普普通通的前端项目、脚本类的东西，或者是那些手头没有专门给构建用的扫描器的项目，是可以去用SonarScanner CLI的；但如果是.NET的项目，那一般就得照着SonarScanner for.NET的那一套方式去配了；碰到Maven、Gradle这一类的项目，也是可以去结合着那些对应的构建工具，来执行扫描的。扫描器这个东西，要是选得不对，项目它倒是有可能照样能把分析给启起来，可是呢，那些构建的信息、依赖的关系，还有覆盖率的数据，就很容易会显得不完整了。
二、sonarQube扫描参数漏填会影响哪些结果
漏掉了扫描参数，这带来的影响，倒不一定就会马上给你蹦出来一个报错。有那么一些参数，要是没填，它是会直接就让你失败的，可也还有另外一些，它会让报告表面上瞧着是有结果出来了，但是里头的内容却缺了一块。后头的这种情况，反而要更加麻烦一些，因为项目里面的人，很有可能会就这么误以为，代码的质量已经被人从头到尾，完整地给检查过一遍了。
1、项目的那个标识要是被漏掉了，会影响到结果的归属
要是项目的Key给配得不对，那扫出来的结果，就有可能跑进一个错掉的项目里面去，再或者，就是会给你生出来一个跟预期完全对不上号的新项目。这样子一来的话，质量门禁、历史的趋势，还有那些对问题追着跑的情况，全都会对不到一块儿去了。对那些带着好多分支、好多仓库的项目来说，项目这个标识，就更加要让它保持得稳稳当当的，可不要每一次跑流水线的时候，都临时去凑出来一个不一样的名字。
2、源码的范围要是漏掉了没填，那会影响到找出来的问题的个数
sonar.sources这个地方，还有排除的规则、测试用的目录，要是配置得不清不楚的，它最直接的一个影响，就是会让扫描的范围跑偏了。源码的目录被漏掉了没填的话，扫出来的问题个数就会往少的那一头偏；可要是把测试的代码、构建生出来的那些产物，还有第三方的库，都给扫进去了，那问题的数量又会虚头巴脑地往上飙。到了最后，你在Bugs、Vulnerabilities、Code Smells这些个地方看到的数字，它很可能就不是这个项目最真实的那种状况了。
3、覆盖率的参数如果漏掉了，会影响到质量门禁那一关
要是测试覆盖率的那个报告，没有被好好地给导进来，那SonarQube它虽然还是能接着去分析代码里面冒出来的问题，可是呢，那些跟覆盖率搭着边的指标，它就会变得缺东少西的，或者是显示得偏低了。好多项目里面设的那个Quality Gate，它都会跑去检查新代码的覆盖率，要是覆盖率报告的路径、格式，或者是生成它的那几步操作，没给配好，那质量门禁这个地方，就有可能会过不去，再或者，它显示在那里的数据，会跟你实际跑测试得出来的结果，对不上号。
4、分支的参数要是漏掉了，会影响到对新代码的判断
去做分支的分析，是需要把当前的这个分支给认对了才行的；在某些个场景底下，是可以去通过sonar.branch.name这么个东西，把分支的名字给指定出来的。分支的参数要是没有给搞明白，扫描跑出来的结果，它就有可能混到主分支的那一摊子里面去，再或者，在判断新代码的范围上，会出些个不对劲的毛病。这么一来二去的，那些新增的问题、修复是往哪个方向在走的趋势，还有质量门禁做出来的判断，全都会跟着受到影响。
三、给SonarQube扫完以后的配置，去做检查的时候，怎么弄才能更稳当一点
把扫描的配置都给弄完了以后，不能光是去瞧一眼流水线它是不是跑成功了，就觉得事情做完了。扫描能跑通，这只不过是才迈出去了第一步，后面还得要去看，跑出来的结果它是不是完整的，是不是进到了那个对的项目里面去，还有各项的指标，它有没有跟原先心里头想的样子，给对上号。
1、先去瞅一眼，项目跟分支它是不是对头的
进到了SonarQube的那个页面以后，要先去把项目的名字、Project Key是哪一个、分支的名字，还有最近一回做分析的时间，都给确认上一遍。要是连这些个最最基础的信息，它都是不对的，那放在后头的那一堆指标，也就没有太大的、值得去拿来做参考的价值了。
2、完了以后，再去看看问题跟覆盖率这一块，是不是有什么不正常的地方
拿着【Issues】、【Coverage】还有【Duplications】这些个地方给出的结果，去跟平时的情况比对比对，看看它是不是有明显的，高得离谱或者是低得离谱的样子。
要是一个大中型的项目，它扫出来的问题个数，突然一下子就变得很少了，那这背后头有可能的原因，就是源码的那个目录，压根儿就没有被扫全；要是覆盖率啪地一下变成了一个零蛋，那通常就得要回过头去，瞧一瞧覆盖率的报告它到底生成了没有，填的那个路径是不是对的，还有CI那边干活用的工作目录，是不是前后都一样的。可不要一上来，就直接觉得是代码的质量，它一下子就猛地变好了，或者是变差了。
3、到了最后，要把那些参数给固定到流水线里面去
在本地机器上，临时敲一敲命令，拿来调一调是没问题的，可是对于一个要长期稳定跑着的项目来说，顶好还是把那些参数，给固定到配置文件，或者是CI的变量里面去。Token这个东西，要搁在那种安全变量里面，源码的范围和那些要排除掉的规则，也得交代得明明白白的，覆盖率报告的路径，也要让它一直保持着一个稳稳当当的样子。这么一来，项目里头的人，就用不着每一回都靠手工去把参数给补上，扫出来的那些结果，在很长的时间里面，也比较容易拿来做对比了。
总结
说到底，在SonarQube里面，扫描项目要怎么去配置，还有扫描的时候参数漏掉了会对哪些结果造成影响，这件事，它最打紧的地方，还是要把项目用来认身份的标识、源码的范围、服务器的地址、认证要用的那些信息、分支，还有覆盖率的参数，都给设得明明白白的。参数被漏掉了，它不一定每一次都会让扫描直接失败，可是它总归是会叫结果的归属、问题的个数、覆盖率、质量门禁，还有对新代码的判断，这些个地方，闹出毛病来。把配置都给做完了以后，是该去查上一查，项目它是不是被扫对了，那些指标是不是都是全乎的，然后，再把那些已经能稳稳当当跑起来的参数，给放进CI的流水线里面去，拿来长期地用。
