持续集成八 sonarQube配置及使用
目录
后面遇到问题会补充进这篇文章
在线安装常会出现安装不了的情况，网络问题，尝试手动安装
插件地址：https://docs.sonarqube.org/display/PLUG/Plugin+Library
插件版本对应关系： https://docs.sonarqube.org/latest/instance-administration/plugin-version-matrix/
下载后将插件复制到： sonarqube/extensions/plugins/
docker安装的地址：/opt/sonarqube/extensions/plugins
有些插件在sonar插件库找不到，比如svn/git或是比较难以下载，我会将我的插件分享到百度网盘
jenkins版本：2.222.1 soanrQube版本：8.2.0.32929
链接：https://pan.baidu.com/s/1uhh21ifBt7CH49lon2s7MQ 提取码：g76i
1.插件
- chinese pack
- sonarJava（Java Code Quality and Security）
- sonarJS
- svn
- git
- build breaker
2.sonar界面配置使用
项目
也可以按照其他条件视图显示项目
质量配置
质量配置中会有插件中的内置规则，我们可以自定义和扩展这些规则
在创建的规则中，左侧面板是规则激活个数，可以点进去，然后选择需要激活和关闭的规则。
在创建的规则中，左侧面板是规则激活个数，可以点进去，然后选择需要激活和关闭的规则。
过滤条件
按分类查询
问题
先选中问题类型，然后选中负责人查看该负责人所有的问题。
代码规则
代码规则列表，不提供修改
点进详细规则中，可以修改它属于哪一个质量配置规则，和这条规则的严重程度。
Build Breaker 构建破坏
下载插件 Build Breaker
在构建时，sonar上的规则不达标时，就会使构建失败
默认值为false，表示build breaker开启
质量阈
然后选择要启用该规则的项目：
以默认规则为例，他的配置是以新代码相对于上一次提交来计算的指标
当这些指标不达标时，在项目总览那里就会显示，并且只要一个不达标就会报错，如果你有配置build breader ，那么你的项目就不会编译通过
对照指标和项目数据，其关系如下图
可靠性：
A = 0个错误
B =至少1个次要错误
C =至少1个主要错误
D =至少1个严重错误
E =至少1个阻止程序错误
安全性:
A = 0漏洞
B =至少1个次要漏洞
C =至少1个主要漏洞
D =至少1个严重漏洞
E =至少1个阻止程序漏洞
可维护：
可以修改
在【配置】【技术债务】
- <= 5％已进入应用程序的时间，等级为A
- 在6至10％之间，评级为B
- 在11％到20％之间，评级为C
- 在21％到50％之间，评级为D
- 任何超过50％的都是E
技术债务
该度量以分钟为单位存储在数据库中。 以天为单位显示值时，假设一天为8小时。
比如我们项目有71000行代码，扫描出的债务为180天，设置的LOC（开发一行的代码时间）为30分钟（默认），那么计算公式为：
180*8*60
—————— = 0.04< 5%(A)
30*71000
指标等级ABCDE
官网说明：https://docs.sonarqube.org/latest/user-guide/metric-definitions/
质量阈
质量阈状态（alert_status）
与您的项目关联的质量门状态。可能的值为：ERROR，OK 自7.6起已删除WARN值。
质量阈详细信息（quality_gate_details）
对于质量阈的所有条件，您都知道哪个条件失败了，哪个不是。
可靠性
错误（bugs）
错误的数量。
新错误（new_bugs）
新错误的数量。
可靠性等级（reliability_rating）
A = 0个错误
B =至少1个次要错误
C =至少1个主要错误
D =至少1个严重错误
E =至少1个阻止程序错误
可靠性补救措施（reliability_remediation_effort）
修复所有错误问题。该度量以分钟存储在数据库中。以天为单位显示值时，假设一天为8小时。
对新代码的可靠性补救措施（new_reliability_remediation_effort）
与对可靠性代码的补救措施相同，但对在新代码期内更改的代码。
安全性
漏洞（vulnerabilities）
漏洞问题的数量。
新代码上的漏洞（new_vulnerabilities）
新漏洞问题的数量。
安全评级（security_rating）
A = 0漏洞
B =至少1个次要漏洞
C =至少1个主要漏洞
D =至少1个严重漏洞
E =至少1个阻止程序漏洞
安全修复工作（security_remediation_effort）
修复所有漏洞问题的工作。该度量以分钟存储在数据库中。以天为单位显示值时，假设一天为8小时。
对新代码的安全修复工作（new_security_remediation_effort）
与安全补救工作相同，但对在新代码周期内更改的代码进行了纠正。
安全热点（security_hotspots）安全热点数
新代码上的安全热点（new_security_hotspots）新代码期内新的安全热点数。
安全审核评分（security_review_rating）
安全审核等级是根据已审核（固定或安全）安全热点的百分比得出的字母等级。
A => = 80％
B => = 70％和<80％
C => = 50％和<70％
D => = 30％和<50％
E = <30％
新代码的安全审查评分（new_security_review_rating）
新代码周期的安全审查评分。
已审查的安全热点（security_hotspots_reviewed）
已审核（固定或安全）安全热点的百分比。
比例公式： Number of Reviewed (Fixed or Safe) Hotspots x 100 / (To_Review Hotspots + Reviewed Hotspots)
审查了新的安全热点
新代码期内已审核的安全热点（固定或安全）的百分比。
代码 异味（code_smells）
代码异味总数。
新代码气味（new_code_smells）
在新代码时段内首次提出的代码气味问题总数。
可维护性等级（sqale_rating）
（以前是SQALE等级。）与您的技术债务比率的值相关的项目评级。默认的“可维护性等级”网格为：
A = 0-0.05，B = 0.06-0.1，C = 0.11-0.20，D = 0.21-0.5，E = 0.51-1
可维护性等级量表可以通过以下方式替代性表示：如果未偿还的修复成本为：
- <= 5％已进入应用程序的时间，等级为A
- 在6至10％之间，评级为B
- 在11％到20％之间，评级为C
- 在21％到50％之间，评级为D
- 任何超过50％的都是E
技术债务（sqale_index）
努力修复所有代码错误。该度量以分钟为单位存储在数据库中。以天为单位显示值时，假设一天为8小时。
新法规的技术债务（new_technical_debt）
努力解决在新法规期内首次提出的所有法规气味。
技术债务比率（sqale_debt_ratio）
开发软件的成本与修复软件的成本之间的比率。技术债务比率公式为：
Remediation cost / Development cost
可以重述为：
Remediation cost / (Cost to develop 1 line of code * Number of lines of code)
开发代码行的成本值为0.06天。
新法规的技术债务比率（new_sqale_debt_ratio）
在新法规期内更改的法规开发成本与与其相关的发行成本之间的比率。
重复项
重复块 数（duplicated_blocks）
行的重复块数。
特定语言的详细信息
对于被视为重复的代码块：
非Java项目：
- 至少应有100个连续令牌和重复令牌。
- 这些令牌应至少散布在：
- COBOL的30行代码
- ABAP的20行代码
- 其他语言的10行代码
Java项目：
无论令牌和行的数量如何，至少应有10个连续和重复的语句。在检测重复项时，缩进和字符串文字的差异将被忽略。
复制的文件（duplicated_files）
复制中涉及的文件数。
重复行（duplicated_lines）
重复中涉及的行数。
重复行（％）（duplicated_lines_density）
= duplicated_lines/ lines* 100
3.配置显示代码作者和负责人
代码一般都是配置再git /svn上的，那么为了让sonar分析的代码可以看出是谁写的或是谁改的，需要集成插件。
配置步骤：
- 配置SCM不要被禁用
- 配置插件；svn需要另外配置账号密码，git不需要。
- 可以使用： -Dsonar.scm.provider=git 强制执行分析
下面是svn的配置，就是需要一个能够去连接svn上项目的账号密码
官方参考： https://docs.sonarqube.org/pages/viewpage.action?pageId=11640438
源码界面：
在左侧空白栏上和idea annotate功能一样，可以显示谁提交的代码，点击空白处，出现详细信息
问题界面：
实现需求：在不登录的情况下就能看到问题的负责人是谁。
注意：要出现上面问题界面的效果，即分配代码责任人，需要在soanrQube上配置用户，而且用户的名称和SVN上的也要一样，密码随便，在分析后就会匹配用户（图中2），然后在左侧条件栏中，会出现所有用户的统计信息（图中1）
这种情况下不需要用户登录，只需要创建对应与SVN的账号就行，sonarQube默认权限是任何人都能访问这些数据，所以不需要过多配置。
问题：
- 如果出现没有自动配置责任人，就像下面的“未分配”，那么这样的情况是因为你在soanr扫描分析代码后才配置的用户，那么，解决办法就是讲sonarQube上的这个项目删除掉（清空数据），然后从新扫描一次，就会根据SVN分配用户了。
2. 出现下面不现实作者只显示时间的情况是未登录，不能查看源码是谁的信息，正常情况。一般情况下，sonarQube自动分配了问题后，也不需要查看源码，不需要修改权限。
SVN的账号密码就用户名和密码，显示也比较清晰。而git我的是显示邮箱，找不到哪里可以配置（待补充）
git集成通过纯Java实现，因此才执行分析的计算机上不需要安装git命令行工具。
git需要显示作者要配置邮箱
注意：需要整个完整克隆，才能收集到责任者信息。
如果出现其他问题和有疑问的请看：https://docs.sonarqube.org/latest/analysis/scm-integration/
4. 数据表示意义
1.行数
在sonar里有几个行的定义：行数、代码行、覆盖率的代码行
行数：指的是文件中所有的行，包括空行回车、注释等
代码行：指定是源代码的行，包括import、类定义行、方法定义行、花括号“}”所占的行
覆盖率的行：指定是有效行，方法内的代码行，不包括“}”
如下面一个类的统计数据，，行数74，真正的代码行64，覆盖率的行只有22（代码不能公开）
这样就会出现这样一种情况，覆盖率里显示的行数和项目显示的行数不对应
2.活动记录
【活动】标签页中，质量阈这个是表示该次扫描结果，其标准是质量阈的标准，Red（红色，也是它图标的颜色）表示错误，was green表示之前版本为green（通过）
把鼠标放到记录列表名称上会出现title提示由那一项规则不通过，但是7.9版本的反应比较慢，不容易被人发现，但是8.2版本的是比较快，我也是在这个版本发现的。
7.9版本
8.2版本
腾讯云开发者
