SonarQube4.4+Jenkins进行代码检查实例之二

在 《SonarQube4.4+Jenkins进行代码检查实例之一》 中介绍了不编译只检查的方式。

但是有些代码检查需要使用字节码,比如Findbugs的检查依赖于字节码,实例一中只提取源代码,就不能进行Findbugs的检查。

要进行Findbugs检查就需要编译。以下实例操作来演示如何搭建

1,首先当然是要下载最新的Findbugs    http://docs.codehaus.org/display/SONAR/FindBugs+Plugin  ,当前最新版是V3.0,  supports analysis of Java 8 bytecode but requires Java 1.7 to run (see Compatibility section)。  下载后将相应Jar包存放到 \sonarqube-4.4\extensions\plugins 下, 其中\sonarqube-4.4是SonarQube的安装目录,然后重启SonarQube

1b, 也可以在SonarQube的update center中下载,下载后按提示重启SonarQube即可。

2,以admin登录到Sonar,将缺省的Quality Profiles改为 Sonar way with Findbugs

3,在Jenkins中配置项目,笔者以Maven3为例,选择 maven2/3项目

4,按Maven项目正常配置,在Goals and options留空,采用缺省

5,在Post Steps中加入 Windows Batch command, 命令为: SonarQube Runner V2.4安装位置\bin\sonar-runner.bat

6,配置项目,要告知SonarQube编译结果在哪里,并且加入更新到SVN下,如下:

# required metadata
sonar.projectKey=Keqiang:CodeKatabySonarRunner
sonar.projectName=CodeKatabySonarRunner
sonar.projectVersion=2.0.0
# path to source directories (required)
sonar.sources=src/main/java
# path to project binaries (optional), for example directory of Java bytecode
sonar.binaries=target/classes

7,在Jenkins中立即构建 此Job

8,访问 http://localhost:9000 来看看SonarQube的结果,可以看到根据Findbugs的规则新发现的issue

说明1:Sonar way with Findbugs 是SonarQube缺省的选择,一共497条规则。SonarQube提供了方便的界面来修改。

说明2:SonarQube就发现的Issue设立了总指标Technical Debt,以工作量来表达需要多少时间修复这些issue。

小结:以上配置是简单的。说白了,只需交待编译结果在哪里就可以了。

以上两个实例,希望读者能够了解搭建SonarQube是多么容易。

Jenkins并不是必须的,利用Sonar-Runner完全可以达到相同相关。加入Jenkins支持之后,就能根据Svn操作来自动启动。

时间: 2024-08-11 19:53:55

SonarQube4.4+Jenkins进行代码检查实例之二的相关文章

SonarQube4.4+Jenkins进行代码检查实例之三-单元测试分析

作者:张克强    作者微博:张克强-敏捷307 在 <SonarQube4.4+Jenkins进行代码检查实例之一> 中介绍了不编译只检查的方式. 在<SonarQube4.4+Jenkins进行代码检查实例之二>中介绍了编译并检查编译结果的方式. 本文来介绍如何利用SonarQube来分析单元测试.最新推荐在分析插件是Jacoco. 当然要进行单元测试,首先单元测试得到了书写,能够本地执行得到结果.本示例采用Maven的典型结构. 1,配置Maven,在maven的conf目录

SonarQube4.4+Jenkins进行代码检查实例之三-单元測试分析

作者:张克强    作者微博:张克强-敏捷307 在 <SonarQube4.4+Jenkins进行代码检查实例之中的一个> 中介绍了不编译仅仅检查的方式. 在<SonarQube4.4+Jenkins进行代码检查实例之二>中介绍了编译并检查编译结果的方式. 本文来介绍怎样利用SonarQube来分析单元測试.最新推荐在分析插件是Jacoco. 当然要进行单元測试,首先单元測试得到了书写,可以本地运行得到结果. 本演示样例採用Maven的典型结构. 1,配置Maven,在maven

SonarQube4.4+Jenkins进行代码检查实例之一

在最新的<关于代码审查的几点建议>中再次提到了代码分析: 6.尽量使用静态代码分析工具以提高审查效率. 笔者之前也谈到过多次代码分析.代码检查,见: 关于代码评审的微博讨论汇集 #敏捷有效实践# 每日代码自动检查 英文是daily code inspection.对代码质量关注时,安排人工检查code review是需要的,但100% code review需要很多工作量,不是所有的组织值得这样做,而工具自动检查是只需少量人工建设配置,99%的组织值得采用.此实践花费不多,收效不小. #CMM

在idea intellij中使用Sonarqube进行代码检查

Sonarqube是一个功能非常强大的代码质量检查.管理的工具.能够识别多种常用的编程语言,并能够通过设置不同的Rule Sonar是一个代码质量管理的开源工具,它通过插件的形式能够识别常见的多种编程语言(例如Java, C#, PHP, Pythod等)代码质量问题.Sonar可以帮你分析出以下代码质量问题: 1.不遵循代码标准 2.潜在的缺陷 3.代码重复 4.注释率不足或过高 5.糟糕的复杂度分布 6.缺乏单元测试 在公司中,一般是把Sonarqube布置在服务器端,当开发人员提交代码时,

Android 代码检查工具SonarQube

http://blog.csdn.net/rain_butterfly/article/details/42170601 代码检查工具能帮我们检查一些隐藏的bug,代码检查工具中sonar是比较好的一个.官网 Sonar 概述 Sonar 是一个用于代码质量管理的开放平台.通过插件机制,Sonar 可以集成不同的测试工具,代码分析工具,以及持续集成工具.与持续集成工具(例如 Hudson/Jenkins 等)不同,Sonar 并不是简单地把不同的代码检查工具结果(例如 FindBugs,PMD

java 命名代码检查-注解处理器

命名代码检查 根据 <Java 语言规范( 第 3 版 ) > 中第6.8节的要求, Java 程序命名应当符合下列格式的书写规范: 类 ( 或接口 ) : 符合驼式命名法, 首字母大写. 方法 : 符合驼式命名法,首字母小写 字段 : 类或实例变量 : 符合驼式命名法 , 首字母小写 常量 : 要求全部有大写字母或下划线构成, 并且第一个字符不能是下划线. 要通过注解处理器的API 实现一个编译器插件 , 首先需要了解这组 API 的基本知识.我们实现注解处理器的代码需要继承抽象类 java

华为软件开发云测评报告二:代码检查

相关文章:<华为软件开发云测评报告一:项目管理> 体验环境 体验方式:PC端 系统:Windows 64位 浏览器类型:Chrome浏览器 浏览器版本:58.0.3029.110 体验时间:2017.06.25 分析目的 了解华为软件开发云的代码检查服务功能,分析其优缺点: 从人工代码检视到自动化代码检查,华为软件开发云如何保证代码质量: 代码检查未来的发展趋势: 产品简介 产品名称:华为软件开发云 定位:软件开发云(DevCloud)是集华为研发实践.前沿研发理念.先进研发工具为一体的研发云

C/C++代码检视实例

相关文章链接如下: 微软过桥问题与测试人员素养 等价类分法 新解 测试用例设计中的NP难题 90%程序员写不出无BUG的二分查找程序? C/C++代码检视要点 4.1             代码检视实例 看完上面的评审检视要点后,也许有些读者已经急切地想找一些代码来试验一下看能否通过上面的内容来提高自己的检视能力.下面就讲几个代码检视的实例,请读者在看这些实例时先不要看后面的分析,自己先拿张纸边看代码边把自己能够发现的问题记录下来,然后再和后面的分析进行比较.如果能够发现后现分析中没有提及的问

FindBugs —— Java 静态代码检查

在使用 Jenkins 构建 Java Web 项目时候,有一项叫做静态代码检查,是用内置的 findBugs 插件,对程序源代码进行检查,以分析程序行为的技术,应用于程序的正确性检查. 安全缺陷检测.程序优化等,特点就是不执行程序.它有助于在项目早期发现以下问题:变量声明了但未使用.变量类型不匹配.变量在使用前未定义.不可达代码.死循环.数组越界.内存泄漏等.分为以下几种类型: 一.Bad Practice (糟糕的写法) 二.Correctness (不太的当) 三.Experimental