Jenkins与sonar扫描的集成问题

记录本周遇到的头疼了很久的一个问题,由于公司需要使用jenkins来自动管理构建项目,然后在关联sonar对项目代码质量进行审核。

接着坑爹的问题来了,原有的技术手段为项目构建成功后通过jenkins的构建后操作去触发提前配置好的sonar服务器对代码质量进行管理,然而处于技术层面以及每次项目构建时间上的考虑,现在需要对原有技术进行替换更新,决定使用在构建中去触发sonar。具体build执行命令如下:

  clean cobertura:cobertura -Dcobertura.report.format=xml  -Dmaven.test.skip=false -Dmaven.test.failure.ignore=true org.sonarsource.scanner.maven:sonar-maven-plugin:3.2:sonar  -X

  目前我们使用的jenkins服务器为远程服务器,同样sonar也为远程服务器。前提(项目本地单元测试没有问题,构建没有问题)。

  在实际jenkins构建中出现以下问题:

  1. 找不到相关依赖的问题。

    此问题出的有一些莫名其妙,总体而言为根据maven配置在我们的本地仓库其实是存在相关依赖的,而且maven的setting文件中也配置了本地仓库地址。

    具体解决方式就更奇葩:为将相关依赖关系在本地仓库移除,并根据包结构重新配置一遍就可以了。

  2.找不到相关工程项目

    我们的项目为多模块项目,在构建的时候根据输出日志可以查看到相关的每个模块的构建均为success,然而在最终整体项目构建的时候报错,根据记录日志提示为找不到相关工程项目。然后我们在到日志地址查看发现项目其实也是存在的。

  具体解决方式:这个问题我们尝试过很多方式,包括更改包结构,统一Git仓库源码地址,单独整合单一模块测试。。等等。。然而均已失败告终。。最后根据build指令去推敲发现是因为build指令并不支持当前配置的soanr版本。。。。所以。。经过利弊权衡,最终我们选择了更换sonar服务器的版本。

最后说一下我们为什么会选择更改sonar版本,而非更改build命令。

  因为我们整个工程下面涉及到19个模块服务,在未做出调整之前我们构建整个项目,并得到最终扫描结果所需要花费的时间大概是4个小时以上。也就是说如果在代码中存在必须要更改的质量问题,改一次然后在测试的成本太高。而通过后面一种方式构建到处sonar结果所需要的时间仅仅10多分钟,可以大幅提升效率。所以还是推荐使用后者。

上一篇:vue-cli的webpack模版,相关配置文件dev-server.js与webpack.config.js配置解析


下一篇:TensorFlow遇到的问题汇总(持续更新中......)