记一次Sonar执行失败的修复

1. 前提      

在提高代码质量方面公司采用的是Jenkins+Sonar的方案，通过设定扫描规则对现有代码工程进行扫描。代码扫描后会产生不同级别的问题，例如Bugs、漏洞、坏味道等。针对每个工程的发布是用Jenkins进行执行的，在代码每次发布的时候都会触发Sonar扫描配置的Jenkins用于对新增代码的问题汇总。

    2.出现的问题

某天质量部同事发企业消息，说我们有个工程的Sonar扫描任务很久都没有执行成功过了，看下是什么问题导致的。当时简单看了一下根据Jekins但是执行的日志看以为是代码文件的行数较大，被Sonar的某个规则给限制住了。具体错误如下：

于是就先咨询了质量部的同事，是否增加了这样的规则，限制了文件的总行数，得到的反馈是最近没有做过改动。

3、问题解决

3.1  既然规则方面没有改动过，那就先看看是不是行数过大的问题吧，把文件内容缩小到一定的行数比如200行，结果报错信息与上面的是一样的，只是变了一下数字。宣告失败

3.2 既然不是文件行数的问题，那就换个方向。清理一下Jenkins工作空间。操作如下：

结果就是扫描失败，失败的错误变了（是个进步终于不在看上面那个错误了）。报错如下：

根据错误提取关键词build，跟编译有关系，然后看下Jenkins的编译配置。结果发现少了如下配置。

工程是采用gradle进行编译打包的，所以缺少了这个过程自然就编译不了了。重新执行Jenkins成功：

并生成了Sonar的扫描报告。至此就算把上面那个问题解决了。

4、总结

中间还有去百度过类似的异常，本来开发只是简单的了解Jenkins的使用，比如执行和发布，从异常看是发生在了Sonar上应该有质量的同事定位好问题，如果确实是代码的问题在交由开发组进行修复。但直接甩给开发也是醉了，百度没能找到对应的类似问题，所以还得自己找思路解决。

综上基本的问题定位是由于没有配置编译脚本，导致编译的class文件不是最新的，代码在变化后不能相对应，导致的问题。

通过1、清理工作空间把旧的编译过的class清除，2、配置编译脚本

留下痕迹做个参考