当前位置: 首页 > 面试题库 >

SonarQube分析未显示代码覆盖率

孟福
2023-03-14
问题内容

我有一个Jenkins项目,对我的NodeJS项目进行SonarQube分析。我添加istanbul了对项目的依赖package.json。在Jenkins构建配置中,首先运行一个shell脚本:

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文件。还检查了构建控制台日志,没有发现错误。我还尝试过使用LCOV格式来提高代码覆盖率:

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

即使在Jenkins工作区中生成了覆盖率报告,该报告也不会发布到SonarQube。我查看了工作区的内容并进行了验证。控制台日志显示生成的覆盖率报告。也试过了

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服务器两次。在StackOverflow和其他地方查看了许多类似的问题,但没有找到任何有效的方法。

如果我添加一个构建后操作Publish Cobetura Coverage Report并在Cobertura xml report pattern字段中指定cobetura-coverage.xml文件的路径,则代码覆盖率报告确实会在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_pa​​cket,我没有MySQL,我需要提高MAX_ALLOWED_PACKET数据库设置中的值。刚完成此操作,然后重新触发了詹金斯的工作以进行SonarQube分析。异常消失了。SonarQube中的后台任务成功。但是我仍然没有在仪表板上看到单元测试代码的覆盖范围。没有其他例外。当我单击“配置小部件”按钮时,单元测试小部件上有“无数据”标签。当我回到仪表板时,“单元测试”小部件消失了。

知道我缺少什么吗?


问题答案:

在我修复了问题中提到的异常之后,lcov报告发布工作正常了。但是有时候,我会随机看到另一个例外。此外,SonarQube仪表板上的单元测试小部件仅显示条件覆盖。需要进一步调整解决方案。

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


 类似资料:
  • 问题内容: 我有一个Jenkins项目,对我的NodeJS项目进行SonarQube分析。我添加了对项目的依赖。在Jenkins构建配置中,首先运行一个shell脚本: 这将安装依赖项,运行测试并生成代码覆盖率报告,并生成cobertura-coverage.xml文件。 在shell脚本之后,我运行具有以下属性的代码覆盖: Jenkins作业通过SonarQube仪表板成功运行,该仪表板描述了项

  • 索纳库贝:8.2。0.32929 声纳扫描仪:3.0。3.778 雅科科:0.8。4 jdk:1.8 mvn:3.6。三, 你想达到什么目标 我试图通过使用sonar scanner实现代码覆盖率,但在sonarqube仪表板中获得代码覆盖率0。 到目前为止,您是如何实现这一目标的 我使用https://github.com/SonarSource/sonar-scanning-examples/

  • 我正在使用Sonarqube分析我的Nestjs项目。当我用jest运行单元测试时,它们都通过了,代码覆盖率约为80%。在Sonarqube上,它仍然显示为0%。 我的sonar-project.properties文件如下 我的jest.json如下 我package.json的相关部分 我的源代码和它们各自的单元测试在同一个位置。测试文件有扩展名。spec.ts 在本地运行测试时,所有测试都通

  • 我将sonarqube jacoco用于codecoverage,我有一个junit测试用例用于我的java代码,它采用的是下面的目录结构。 我希望在sonarqube仪表板上有一个代码覆盖率,我也在使用gradle。 我正在运行gradle sonarqube 我不知道我哪里做错了?如果有任何一个可以帮助从java代码中获得测试用例的覆盖面。

  • 我尝试在我的应用程序模块中的代码的AndroidKotlin应用程序的声纳Qube中显示测试覆盖范围。我可以生成雅各的覆盖结果并显示声纳Qube分度仪,但问题是测试覆盖范围未显示在声纳Qube中: https://imgur.com/a/xOjxLl1 在我的项目的build.gradle中,我有: 在我的身体里。我的应用程序模块的gradle 我生成我的Jacoco报告: 并使用:生成我的son

  • 我有一个多模块项目,我似乎无法在Sonarqube上获得准确的单元测试代码覆盖率报告。我使用buildr和JaCoCo生成测试覆盖率。文件继承类似于下面。 项目--module1----reports----Jacoco------Jacoco.cov(jacoco执行文件,以前用作.exec)--module2--reports----Jacoco(生成的HTML、CSV和XML报表文件)---