Sonarcloud scan started failing with java.lang.NoClassDefFoundError: org/sonar/batch/bootstrapper/EnvironmentInformation

Have been successfully running sonar scans on our project for a number of weeks now but have recently started seeing failures with this error.

Has anyone seen this start happening previously? Any idea what causes it/how to fix?

Thanks in advance.

  • ALM used - GitLab
  • CI system used - GitLab
	at org.sonarsource.scanner.api.internal.batch.DefaultBatchFactory.createBatch(DefaultBatchFactory.java:32)
	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)
Caused by: java.lang.ClassNotFoundException: org.sonar.batch.bootstrapper.EnvironmentInformation```

Hey there.

Some users running into this issue before have fixed it doing this:

Of course, that doesn’t tell us what changed or why it suddenly stopped working – but it might be worth a try to see if it’s the same issue and get you unblocked for now.

It turned out in our GitLab CI pipeline we were caching some stuff from the sonar job and this cache had been poisoned/corrupted so this was causing the failure of the job. We cleared the runner caches in GitLab and the job started working again.

From a Sonar point of view is there an easy way to check the contents of the cache are unimpaired before running the main sonar scan job? I’m thinking of some kind of dummy job that runs against nothing/very little and doesn’t report results to anywhere or just builds the scanner?

Obviously the fix is not to cache things in such a way as to corrupt/poison the cache but it would be helpful to be able to detect a bad cache and clear it prior to the main job running also.

As far as I’m aware there isn’t a mechanism to invalidate the cache – just to make sure it’s clear, how were you able to tell that it was poisoned/corrupted?

It was mostly trial and error, we’ve been seeing cache problems with some of the other jobs in our GitLab pipeline so when we changed the sonar.userhome to a different directory and it worked we thought it may be a cache issue so we cleared the runner caches to confirm and the job has started working.

For invalidating the cache this is something we can do in a GitLab job but is there a minimal sonar command we could run that would use the cache but not run a full scan?

Hey @timb

There isn’t.

I"m curious – do you have an example of another tool that accomplishes something similar?

hey,

Nothing springs to mind.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.