Blank scanning results, JAVA error

SonarQube server Version: v10.5.1 (90531)
DevOps (on-prem) Version: 20240130.2
SQ analysis task version: 5.20.0
SQ installation method: Local docker instance
What are you trying to achieve
Working SQ analysis of a DevOps PullRequest. This used to work, but is now silently failing.

Specifically if the build operation returns SQ errors these will get ignored and will not be reported (neither on the PR level in DevOps nor in the “PR branch” inside SonarQube).

The Code Analysis task seems to crash at the end with:

##[error]Exception in thread "Thread-1" java.lang.NoClassDefFoundError: ch/qos/logback/classic/spi/ThrowableProxy
Exception in thread "Thread-1" java.lang.NoClassDefFoundError: ch/qos/logback/classic/spi/ThrowableProxy
##[error]at ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:145)
	at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:424)
	at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:386)
	at ch.qos.logback.classic.Logger.error(Logger.java:543)
	at org.eclipse.jgit.internal.util.ShutdownHook.cleanup(ShutdownHook.java:87)
	at java.base/java.lang.Thread.run(Thread.java:1589)
Caused by: java.lang.ClassNotFoundException: ch.qos.logback.classic.spi.ThrowableProxy
	at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445)
	at org.sonarsource.scanner.api.internal.IsolatedClassloader.loadClass(IsolatedClassloader.java:82)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
	at ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:145)
	at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:424)
	at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:386)
	at ch.qos.logback.classic.Logger.error(Logger.java:543)
	at org.eclipse.jgit.internal.util.ShutdownHook.cleanup(ShutdownHook.java:87)
	at java.base/java.lang.Thread.run(Thread.java:1589)
Caused by: java.lang.ClassNotFoundException: ch.qos.logback.classic.spi.ThrowableProxy
	at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445)
	at org.sonarsource.scanner.api.internal.IsolatedClassloader.loadClass(IsolatedClassloader.java:82)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
##[error]... 6 more

Does this error also prevent posting SQ results?

In addition to this it seems our code coverage has stopped working as well with 10.5.1 (where it was working fine before) with the following:

CodeCoverage.exe is deprecated. Use dotnet-coverage global tool or Microsoft.CodeCoverage.Console instead. Some features of CodeCoverage.exe will be removed in next release of Visual Studio.

Usage: CodeCoverage <command>

Process returned exit code -1
Coverage report conversion completed successfully.
##[error]Failed to convert the binary code coverage reports to XML. No code coverage information will be uploaded to the server (SonarQube/SonarCloud).
Failed to convert the binary code coverage reports to XML. No code coverage information will be uploaded to the server (SonarQube/SonarCloud).
##[error]Check that the downloaded code coverage file (C:\azp\agent\_work\_temp\0039191f-bd23-421e-9f2c-5b3977a4777d\DevOpsAgent$_SRV-DCK-P03-DEF_2024-05-27.16_10_29.coverage) is valid by opening it in Visual Studio. If it is not, check that the internet security settings on the build machine allow files to be downloaded from the Team Foundation Server machine.
Check that the downloaded code coverage file (C:\azp\agent\_work\_temp\0039191f-bd23-421e-9f2c-5b3977a4777d\DevOpsAgent$_SRV-DCK-P03-DEF_2024-05-27.16_10_29.coverage) is valid by opening it in Visual Studio. If it is not, check that the internet security settings on the build machine allow files to be downloaded from the Team Foundation Server machine.

This is all under the 5.20.0 SonarQubeAnalyze@5 DevOps pipeline task.

Note that we’re using Docker-based DevOps agents. These agents get “remade” by Docker after each job, so they’re particularly “fresh” and there’s no connectivity issues (since each new instance needs to re-register with DevOps).

EDIT: All of the above issues have appeared after upgrading to 10.5.1. I’ve just downgraded our instance to 10.4.1 and all problems are gone. Clearly something appears to be wrong with this latest version…

Hey there.

It shouldn’t, and isn’t for other users. Do you see a successful analysis posted to the URL you expect right above this error?

This might be related to this other post:

Did you also happen to upgrade the version of VSTest used?

OK, so I managed to figure out the CodeCoverage issue, and it’s unrelated to SQ (just… bad timing).

That was due to the faulty Docker image provided by MS (which we’re using for our Docker-based pipelines). Specifically in mcr.microsoft.com/dotnet/framework/sdk:4.8.1 CodeCoverage.exe is faulty, whereas in the tag 4.8.1-20240312-windowsservercore-ltsc20221 it’s working fine.

As for publishing of results, I probably used the wrong word (my apologies). SQ certainly got some data (new branch / PR), as did DevOps, but it seems no issues were identified. This looks fine, except 10.4.1 would definitely identify… “something” even if it was something minor.

If there’s code that should be raising an issue, we’re happy to look into it if you can give us more details. Maybe you just wrote some real clean code this time. :wink:

Well now I feel like a fool.

I had rolled back our SQ instances and now I’ve upgraded for this one test, with the CodeCoverage fix in place, and you’re correct. Things get published as they should. So all we’re left is the exception being thrown by SQ Analyse step and messing up the pipeline logs a little bit, but other than that things seem to be working fine.

I’m still reluctant to fully upgrading to 10.5.1… I think I’ll wait until this background exception is fixed however, otherwise it might send other people from our org into a wild goose chase (like me).

Possibly delete this entire thread too? The key bit here is the faulty task (which is already worked on, AFAIK) and a strange problem with a Windows Docker image (which is unrelated to SQ).