Running the same exact MR branch after upgraded to 9.5.
It does not break for any other kind of branches.
Anything I can do other than go back to 9.4?
Thanks.
INFO: SonarScanner 4.7.0.2747
INFO: Java 11.0.1 Oracle Corporation (64-bit)
INFO: Linux 4.15.0-180-generic amd64
INFO: Analyzing on SonarQube server 9.5.0.56709
Jenkins Linux with GitLab Branch Source 625.v85cf3a_400cfe
INFO: ------------------------------------------------------------------------
INFO: EXECUTION FAILURE
INFO: ------------------------------------------------------------------------
INFO: Total time: 16.396s
INFO: Final Memory: 27M/97M
INFO: ------------------------------------------------------------------------
ERROR: Error during SonarScanner execution
java.lang.UnsupportedOperationException
at org.sonar.java.model.GeneratedFile.status(GeneratedFile.java:201)
at org.sonar.java.SonarComponents.fileCanBeSkipped(SonarComponents.java:476)
at org.sonar.java.model.VisitorsBridge.scanWithoutParsing(VisitorsBridge.java:179)
at java.base/java.util.stream.Collectors.lambda$partitioningBy$62(Collectors.java:1381)
at java.base/java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
at java.base/java.util.HashMap$ValueSpliterator.forEachRemaining(HashMap.java:1675)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
at org.sonar.java.ast.JavaAstScanner.scanWithoutParsing(JavaAstScanner.java:80)
at org.sonar.java.JavaFrontend.scan(JavaFrontend.java:145)
at org.sonar.plugins.java.JavaSensor.execute(JavaSensor.java:113)
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.SpringModuleScanContainer.doAfterStart(SpringModuleScanContainer.java:81)
at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:188)
at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:167)
at org.sonar.scanner.scan.SpringProjectScanContainer.scan(SpringProjectScanContainer.java:392)
at org.sonar.scanner.scan.SpringProjectScanContainer.scanRecursively(SpringProjectScanContainer.java:388)
at org.sonar.scanner.scan.SpringProjectScanContainer.doAfterStart(SpringProjectScanContainer.java:357)
at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:188)
at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:167)
at org.sonar.scanner.bootstrap.SpringGlobalContainer.doAfterStart(SpringGlobalContainer.java:135)
at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:188)
at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:167)
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)
Another suggestion to fix this one is to “prevent” SonarQube from reaching the analyses cache url. Note this solution can be of course only be implemented on server side.
This will actually prevent to cache to be used from a pipeline. Tested this and it works fine. Be aware that some SonarQube scans can take alot longer when the analyses cache is disabled.
Hey there,
Just to let you know that the patch to this bug has shipped as part of SonarQube 9.6 with better support of incremental analysis for Java code in PR/MR.
Just for clarity, how can we check which version of Sonar-Java is being used by each SonarQube version?
I could not easily find a matrix table, or the point in code where the plugin version is defined, or a commit updating. So when I take a look at the release upgrade notes, or at the full release notes, I can not see how would I know this is fixed.
thank you for the fix, this is awesome. But when the bug hit us big on a 9.5 upgrade. The fix version “7.12” in the SONARJAVA project does not appear in the release notes for 9.6 or 9.5.
How can we make the link between SONARJAVA 7.12 and SONAR 9.6?
Hey @colmcd,
Indeed, the fixes are not visible in the 9.6 release notes, but it is more of a clerical issue. I have now added the fix of 7.13 to the ticket.
Regarding the release notes of sonar-java, apart from LTS-related releases, you can assume that changes are applied linearly. Unless stated otherwise, fixes from previous versions still apply to the current version.