Failure during analysis, Node.js command to start eslint-bridge server was not built yet

Template for a good bug report, formatted with Markdown:

  • Versions used (SonarQube, Scanner, Plugin, and any relevant extension)
  • SonarQube: 9.3.0.51899, 8.9.7, 8.9.3
  • Scanner: 4.6.0.2311, 4.6.2.2472, 4.6.1.2450
  • Error observed (wrap logs/code around triple quote ``` for proper formatting)
18:36:29.303 DEBUG: Deploying bundle
18:36:29.311 DEBUG: Deploying eslint-bridge into /usr/src/.scannerwork/.sonartmp/eslint-bridge-bundle
18:36:34.651 ERROR: Failure during analysis, Node.js command to start eslint-bridge server was not built yet.
java.util.zip.ZipException: Corrupt GZIP trailer
	at java.base/java.util.zip.GZIPInputStream.readTrailer(GZIPInputStream.java:226)
	at java.base/java.util.zip.GZIPInputStream.read(GZIPInputStream.java:120)
	at java.base/java.util.zip.InflaterInputStream.skip(InflaterInputStream.java:213)
	at org.apache.commons.compress.utils.IOUtils.skip(IOUtils.java:121)
	at org.apache.commons.compress.archivers.tar.TarArchiveInputStream.consumeRemainderOfLastBlock(TarArchiveInputStream.java:848)
	at org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getRecord(TarArchiveInputStream.java:536)
	at org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:370)
	at org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:671)
	at org.sonar.plugins.javascript.eslint.BundleUtils.extractFromClasspath(BundleUtils.java:46)
	at org.sonar.plugins.javascript.eslint.BundleImpl.deploy(BundleImpl.java:62)
	at org.sonar.plugins.javascript.eslint.EslintBridgeServerImpl.deploy(EslintBridgeServerImpl.java:114)
	at org.sonar.plugins.javascript.eslint.EslintBridgeServerImpl.startServerLazily(EslintBridgeServerImpl.java:199)
	at org.sonar.plugins.javascript.eslint.AbstractEslintSensor.execute(AbstractEslintSensor.java:66)
	at org.sonar.plugins.javascript.eslint.CssRuleSensor.execute(CssRuleSensor.java:89)
	at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:64)
	at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:85)
	at org.sonar.scanner.sensor.ModuleSensorsExecutor.lambda$execute$1(ModuleSensorsExecutor.java:59)
	at org.sonar.scanner.sensor.ModuleSensorsExecutor.withModuleStrategy(ModuleSensorsExecutor.java:77)
	at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:59)
	at org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:79)
	at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:137)
	at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:123)
	at org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:384)
	at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:380)
	at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:349)
	at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:137)
	at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:123)
	at org.sonar.scanner.bootstrap.GlobalContainer.doAfterStart(GlobalContainer.java:136)
	at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:137)
	at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:123)
	at org.sonar.batch.bootstrapper.Batch.doExecute(Batch.java:72)
	at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:66)
	at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:46)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60)
	at com.sun.proxy.$Proxy0.execute(Unknown Source)
	at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:189)
	at org.sonarsource.scanner.api.EmbeddedScanner.execute(EmbeddedScanner.java:138)
	at org.sonarsource.scanner.cli.Main.execute(Main.java:112)
	at org.sonarsource.scanner.cli.Main.execute(Main.java:75)
	at org.sonarsource.scanner.cli.Main.main(Main.java:61)
  • Steps to reproduce
  • Run PHP analysis via Jenkins
  • Potential workaround
  • I have tried everything I could think off. Upgrading/downgrading Sonar, Sonarqube-cli, moved my analysis into a docker container to ensure no dependencies on my Jenkins server were causing the issue, increased the memory of my Jenkins server, deleted all plugins on the Sonar server.
  • Scanner command used when applicable (private details masked)
            withSonarQubeEnv(installationName: 'Sonar', credentialsId: 'Sonar') {
              sh 'sonar/bin/sonar-scanner'
            }
docker run --rm -e SONAR_HOST_URL="${SONAR_HOST_URL}" -e SONAR_LOGIN="${SONAR_AUTH_TOKEN}" -v "${WORKSPACE}:/usr/src" sonarsource/sonar-scanner-cli

oh, and the analysis seems to complete correctlyā€¦

21:36:01.714 DEBUG: POST 200 https://sonar......com/api/ce/submit?projectKey=....&projectName=.... | time=363ms
21:36:01.720 INFO: Analysis report uploaded in 369ms
21:36:01.721 DEBUG: Report metadata written to /var/lib/jenkins/workspace/..../.scannerwork/report-task.txt
21:36:01.721 INFO: ANALYSIS SUCCESSFUL, you can browse https://sonar.,,,,.com/dashboard?id=....
21:36:01.721 INFO: Note that you will be able to access the updated dashboard once the server has processed the submitted analysis report
21:36:01.721 INFO: More about the report processing at https://sonar......com/api/ce/task?id=AX_2E7drk4xl5rrXvW5e
21:36:01.725 DEBUG: Post-jobs :
21:36:02.799 INFO: Analysis total time: 1:49.086 s
21:36:02.802 INFO: ------------------------------------------------------------------------
21:36:02.802 INFO: EXECUTION SUCCESS
21:36:02.802 INFO: ------------------------------------------------------------------------
21:36:02.803 INFO: Total time: 1:54.216s
21:36:02.889 INFO: Final Memory: 17M/102M
21:36:02.889 INFO: ------------------------------------------------------------------------

but then on the server, the background task is ā€˜failedā€™ with the following error:

java.lang.IllegalStateException: Fail to extract report AX_2E7drk4xl5rrXvW5e from database
	at org.sonar.ce.task.projectanalysis.step.ExtractReportStep.execute(ExtractReportStep.java:73)
	at org.sonar.ce.task.step.ComputationStepExecutor.executeStep(ComputationStepExecutor.java:81)
	at org.sonar.ce.task.step.ComputationStepExecutor.executeSteps(ComputationStepExecutor.java:72)
	at org.sonar.ce.task.step.ComputationStepExecutor.execute(ComputationStepExecutor.java:59)
	at org.sonar.ce.task.projectanalysis.taskprocessor.ReportTaskProcessor.process(ReportTaskProcessor.java:81)
	at org.sonar.ce.taskprocessor.CeWorkerImpl$ExecuteTask.executeTask(CeWorkerImpl.java:212)
	at org.sonar.ce.taskprocessor.CeWorkerImpl$ExecuteTask.run(CeWorkerImpl.java:194)
	at org.sonar.ce.taskprocessor.CeWorkerImpl.findAndProcessTask(CeWorkerImpl.java:160)
	at org.sonar.ce.taskprocessor.CeWorkerImpl$TrackRunningState.get(CeWorkerImpl.java:135)
	at org.sonar.ce.taskprocessor.CeWorkerImpl.call(CeWorkerImpl.java:87)
	at org.sonar.ce.taskprocessor.CeWorkerImpl.call(CeWorkerImpl.java:53)
	at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:125)
	at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:69)
	at com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:78)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.util.zip.ZipException: invalid entry CRC (expected 0x3387d439 but got 0x5481b075)
	at java.base/java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:410)
	at java.base/java.util.zip.ZipInputStream.read(ZipInputStream.java:199)
	at java.base/java.io.FilterInputStream.read(FilterInputStream.java:107)
	at org.sonar.api.internal.apachecommons.io.IOUtils.copyLarge(IOUtils.java:1309)
	at org.sonar.api.internal.apachecommons.io.IOUtils.copy(IOUtils.java:978)
	at org.sonar.api.internal.apachecommons.io.IOUtils.copyLarge(IOUtils.java:1282)
	at org.sonar.api.internal.apachecommons.io.IOUtils.copy(IOUtils.java:953)
	at org.sonar.api.utils.ZipUtils.copy(ZipUtils.java:152)
	at org.sonar.api.utils.ZipUtils.unzipEntry(ZipUtils.java:102)
	at org.sonar.api.utils.ZipUtils.unzip(ZipUtils.java:86)
	at org.sonar.api.utils.ZipUtils.unzip(ZipUtils.java:63)
	at org.sonar.ce.task.projectanalysis.step.ExtractReportStep.execute(ExtractReportStep.java:71)
	... 19 more

Hi,

Welcome to the community!

Thanks for the follow-up post. With it, it looks like thereā€™s something interfering with the transmission of zip files to/from analysisā€¦? Do you maybe have a ā€œhelpfulā€ proxy between analysis and your SonarQube server?

Ā 
Ann

Any luck with this? I am getting the same issue with server 8.9 LTS and scanner 4.7.

Trying to scan a typescript project and the ts/tsx files are ignored. Only CSS and HTML are scanned.

Hi @kxt5258,

Welcome to the community!

If youā€™re actually getting an analysis, then itā€™s probably not the same problem. Could you create a new thread, please?

Ā 
Ann

Sure @ganncamp , will do. However, I feel it is the same issue. Looks like an issue with the docker image.

There is a Traefik server in between the server running the analysis and the server (docker) thatā€™s running Sonar, but that has been there for about a year without problems.

Also, Iā€™ve done some more testing and found a combination that does work:
Iā€™m now running 9.3.0.51899 on the server and sonarsource/sonar-scanner-cli:4.6 (4.6.2.2472 on docker) for analysis. This docker runs on a different machine then the server, so the Traefik proxy is still in between. Oddly enough, if I switch to 4.6.2.2472 outside of docker, running straight on the Linux machine, the problem is back, but if I switch to a newer version on docker, I also get the issue back.

Hi,

While I still suspect interference, weā€™ve seen something similar once before but werenā€™t able to get to the root of it, so Iā€™ve flagged this for more expert attention.

And I want to point out that youā€™re on neither the latest version of SQ nor the scanner.

And it might be useful to try a different Java distro in the meantime.

Ā 
Ann

Hey guys, @Jeroen @ganncamp

Iā€™m facing this issue, too.
I checked it, due to docker image latest of sonarsource.

How to resolve?
Please change docker image from sonarsource/sonar-scanner-cli:latest => sonarsource/sonar-scanner-cli:4.6

Later, if docker image of sonarsource is Ok, we can change back.

1 Like

Sure.
Please change docker image from sonarsource/sonar-scanner-cli: latest => sonarsource/sonar-scanner-cli: 4.6
It will works.

@Colin @ganncamp Please close this topic and mark answer as resolved.

@Colin @ganncamp Please close this topic and mark answer as resolved.

Sorry??
First of all, you didnā€™t open the topic. Secondly, falling back to a year old version is NOT a solution.

From my attempts from fixing the same ZipException in our installation it seems to have a relation to the report size.
The ZipException only occured in one of our projects main branch analysis (report size ~30MB) while other projects main branch analysis (report size ~3MB) worked perfectly fine with the lastest 4.7 SonarScanner. The projects are identical in set up and configuration.

Reverting to the 4.6 does work as already found.

2 Likes

Hey @Jeroen @thachnv92 @SteveSi

See this update here: