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…