SonarQube分析不显示代码覆盖率

问题描述 投票:2回答:2

我有一个Jenkins项目来对我的NodeJS项目进行SonarQube分析。我在项目中添加了 istanbul 作为我项目的 package.json. 在Jenkins构建配置中,首先我运行了一个shell脚本,这将安装依赖关系,运行测试并生成代码覆盖率报告,并生成cobertura-coverage.xml文件。

cd ./project-name
npm install
node_modules/.bin/istanbul cover ./node_modules/.bin/_mocha path-to-unit-tests
node_modules/.bin/istanbul report cobertura
cd ..

这将安装依赖关系,运行测试,生成代码覆盖率报告,并生成cobertura -coverage.xml文件。

在shell脚本之后,我运行了一个 Invoke Standalone SonarQube Analysis 具有以下属性的代码覆盖率。

sonar.java.coveragePlugin=cobertura
sonar.dynamicAnalysis=reuseReports
sonar.cobertura.reportPath=./project-name/coverage/cobertura-coverage.xml

Jenkins作业运行成功,SonarQube仪表盘描述了项目的各种情况,比如代码行数,技术债务,问题等等。但是单元测试的代码覆盖率并没有显示在SonarQube仪表板上。我确保仪表板上有单元测试小部件。

Version of SonarQube server: 5.2
Version of JavaScript plguin used on SonarQube: 2.9
Version of Cobertura plugin used on SonarQube: 1.6.3
Version of Cobertura plugin used on Jenkins: 1.9.7
Version of NodeJS plugin used on Jenkins: 0.2.1

我验证了工作区确实有 "单元测试 "小组件。cobertura-coverage.xml 文件。也检查了构建控制台的日志,没有发现任何bug。我之前也尝试过使用LCOV格式推送代码覆盖率。

sonar.dynamicAnalysis=reuseReports
sonar.javascript.lcov.reportPath=./project-name/coverage/lcov.info

报告没有被发布到SonarQube,即使覆盖率报告确实在Jenkins工作区生成。我看了工作区的内容,并进行了验证。控制台日志显示覆盖报告正在生成。也尝试了

sonar.dynamicAnalysis=reuseReports
sonar.javascript.lcov.reportPath=project-name/coverage/lcov.info

sonar.dynamicAnalysis=reuseReports
sonar.cobertura.reportPath=project-name/coverage/cobertura-coverage.xml

但无济于事。我还重启了Jenkins和SonarQube服务器各2次。在StackOverflow和其他地方看了很多类似的问题,但没有找到任何有效的方法。

如果我添加一个构建后的动作 Publish Cobetura Coverage Report 并指定cobetura-coverage.xml文件的路径。Cobertura xml report pattern 字段,代码覆盖率报告确实会在Jenkins中发布。

看了SonarQube的后台任务日志,看到了一个异常。

java.lang.IllegalStateException: Cannot persist sources of project-key:project-name/node_modules/jscs/jscs-browser.js
at     org.sonar.server.computation.step.PersistFileSourcesStep$FileSourceVisitor.visitFile(PersistFileSourcesStep.java:132) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.component.DepthTraversalTypeAwareCrawler.visitNode(DepthTraversalTypeAwareCrawler.java:72) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.component.DepthTraversalTypeAwareCrawler.visit(DepthTraversalTypeAwareCrawler.java:44) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.component.DepthTraversalTypeAwareCrawler.visitChildren(DepthTraversalTypeAwareCrawler.java:91) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.component.DepthTraversalTypeAwareCrawler.visit(DepthTraversalTypeAwareCrawler.java:47) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.component.DepthTraversalTypeAwareCrawler.visitChildren(DepthTraversalTypeAwareCrawler.java:91) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.component.DepthTraversalTypeAwareCrawler.visit(DepthTraversalTypeAwareCrawler.java:47) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.step.PersistFileSourcesStep.execute(PersistFileSourcesStep.java:89) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.step.ComputationStepExecutor.execute(ComputationStepExecutor.java:39) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.taskprocessor.report.ReportTaskProcessor.process(ReportTaskProcessor.java:53) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.taskprocessor.CeWorkerRunnableImpl.executeTask(CeWorkerRunnableImpl.java:78) [sonar-server-5.2.jar:na]
at org.sonar.server.computation.taskprocessor.CeWorkerRunnableImpl.run(CeWorkerRunnableImpl.java:55) [sonar-server-5.2.jar:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_45-internal]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [na:1.8.0_45-internal]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_45-internal]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [na:1.8.0_45-internal]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_45-internal]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_45-internal]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45-internal]
Caused by: org.apache.ibatis.exceptions.PersistenceException: 
### Error updating database.  Cause: com.mysql.jdbc.PacketTooBigException:     Packet for query is too large (7989143 > 4194304). You can change this value on the server by setting the max_allowed_packet' variable.
### The error may involve org.sonar.db.source.FileSourceMapper.insert-Inline
### The error occurred while setting parameters
### SQL: INSERT INTO file_sources (project_uuid, file_uuid, created_at, updated_at, binary_data, line_hashes, data_hash,     src_hash, data_type, revision)     VALUES (?, ?, ?,     ?, ?, ?,     ?, ?,?,     ?)
### Cause: com.mysql.jdbc.PacketTooBigException: Packet for query is too large (7989143 > 4194304). You can change this value on the server by setting the max_allowed_packet' variable.
at org.apache.ibatis.exceptions.ExceptionFactory.wrapException(ExceptionFactory.java:26) ~[mybatis-3.2.7.jar:3.2.7]
at org.apache.ibatis.session.defaults.DefaultSqlSession.update(DefaultSqlSession.java:154) ~[mybatis-3.2.7.jar:3.2.7]
at org.apache.ibatis.session.defaults.DefaultSqlSession.insert(DefaultSqlSession.java:141) ~[mybatis-3.2.7.jar:3.2.7]
at org.apache.ibatis.binding.MapperMethod.execute(MapperMethod.java:51) ~[mybatis-3.2.7.jar:3.2.7]
at org.apache.ibatis.binding.MapperProxy.invoke(MapperProxy.java:52) ~[mybatis-3.2.7.jar:3.2.7]
at com.sun.proxy.$Proxy84.insert(Unknown Source) ~[na:na]
at org.sonar.db.source.FileSourceDao.insert(FileSourceDao.java:117) ~[sonar-db-5.2.jar:na]
at org.sonar.server.computation.step.PersistFileSourcesStep$FileSourceVisitor.persistSource(PersistFileSourcesStep.java:160) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.step.PersistFileSourcesStep$FileSourceVisitor.visitFile(PersistFileSourcesStep.java:130) ~[sonar-server-5.2.jar:na]
... 18 common frames omitted
Caused by: com.mysql.jdbc.PacketTooBigException: Packet for query is too large (7989143 > 4194304). You can change this value on the server by setting the max_allowed_packet' variable.
at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3540) ~[mysql-connector-java-5.1.35.jar:5.1.35]
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2417) ~[mysql-connector-java-5.1.35.jar:5.1.35]
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2582) ~[mysql-connector-java-5.1.35.jar:5.1.35]
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2535) ~[mysql-connector-java-5.1.35.jar:5.1.35]
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1911) ~[mysql-connector-java-5.1.35.jar:5.1.35]
at com.mysql.jdbc.PreparedStatement.execute(PreparedStatement.java:1203) ~[mysql-connector-java-5.1.35.jar:5.1.35]
at org.apache.commons.dbcp.DelegatingPreparedStatement.execute(DelegatingPreparedStatement.java:172) ~[commons-dbcp-1.4.jar:1.4]
at org.apache.commons.dbcp.DelegatingPreparedStatement.execute(DelegatingPreparedStatement.java:172) ~[commons-dbcp-1.4.jar:1.4]
at org.apache.ibatis.executor.statement.PreparedStatementHandler.update(PreparedStatementHandler.java:44) ~[mybatis-3.2.7.jar:3.2.7]
at org.apache.ibatis.executor.statement.RoutingStatementHandler.update(RoutingStatementHandler.java:69) ~[mybatis-3.2.7.jar:3.2.7]
at org.apache.ibatis.executor.ReuseExecutor.doUpdate(ReuseExecutor.java:50) ~[mybatis-3.2.7.jar:3.2.7]
at org.apache.ibatis.executor.BaseExecutor.update(BaseExecutor.java:105) ~[mybatis-3.2.7.jar:3.2.7]
at org.apache.ibatis.executor.CachingExecutor.update(CachingExecutor.java:71) ~[mybatis-3.2.7.jar:3.2.7]
at org.apache.ibatis.session.defaults.DefaultSqlSession.update(DefaultSqlSession.java:152) ~[mybatis-3.2.7.jar:3.2.7]
... 25 common frames omitted

所以现在我把shell脚本的代码覆盖率生成行更新为

node_modules/.bin/istanbul cover -x node_modules ./node_modules/.bin/_mocha path-to-unit-tests

还是得到了异常。基于 max_allowed_packet,我没有MySQL的。的值,我需要把 MAX_ALLOWED_PACKET 的数据库设置中。刚做完这些,重新触发了SonarQube分析的Jenkins作业。异常消失了。SonarQube中的后台任务成功了。但我仍然没有在仪表板中看到单元测试代码覆盖率。没有其他异常。当我点击 "配置部件 "按钮时,单元测试部件上有 "无数据 "标签。当我回到仪表板时,单元测试小组件消失了。

有什么问题吗?

node.js jenkins sonarqube cobertura istanbul
2个回答
0
投票

在我修复了问题中提到的异常后,lcov报告发布工作了。但有时,我随机看到另一个异常。此外,SonarQube仪表板上的单元测试小组件只显示了Conditionals覆盖率。需要对解决方案进行更多的微调。

sonar.dynamicAnalysis=reuseReports
sonar.javascript.lcov.reportPath=project-name/coverage/lcov.info

0
投票

第一次(大约一年前),当我开始探索 "Sonarqube "时,在进行设置时,一切都很好。我能够看到所有的指标以及"代码覆盖率".

对于该二手版本是Sonarque-6.7.5, sonar-scanner: sonar-scanner-3.2.0.1227-macosx.

在那之后,当我今天为其他项目尝试时,我花了近3个小时来确定为什么代码覆盖率没有在sonarqube报告中显示,尽管一切都配置正确。

在花了一些时间后,我发现以下两个博客主题,这有助于我理解为什么我没有得到覆盖率报告。

如果我没有看错的话,似乎有一个bug,在""之后的""。lcov"报告路径虽然配置准确,但无法识别。

参考链接。

无法获得javascript的代码保护

修复: js-coverage-doesnt-work-anymore。

使用的版本。 Sonarqube:8.3.0 & newtmitchsonar-scanner作为声纳扫描器的Docker镜像。

供参考。 我的本地设置中的Docker文件是用来运行声纳扫描器的。

FROM newtmitch/sonar-scanner AS sonarqube_scan
COPY . /usr/src
RUN ls -list
RUN sonar-scanner \
    -Dsonar.host.url="http://localhost:9000" \
    -Dsonar.projectKey="test-node-app" \
    -Dsonar.projectVersion="1.0" \
    -Dsonar.sources="/usr/src" \
    -Dsonar.language="javascript" \
    -Dsonar.sourceEncoding="UTF-8" \
    -Dsonar.dynamicAnalysis="reuseReports" \
    -Dsonar.javascript.lcov.reportPaths="/usr/src/app/coverage/lcov.info"

我希望有人能帮到你!

学习愉快

最新问题
© www.soinside.com 2019 - 2025. All rights reserved.