Sonar Scanner CLI 6.0 stand alone Azure DevOps fails, 5.0 works, on self hosted agent behind proxy

SonarQube Cloud
, ,
1

We use Azure DevOps, running a dotnet build with SonarCloud standalone scanner, using v2 of the SonarCloud tasks, without a value for the Scanner CLI

Yesterday it worked fine with CLI version 5.0.1.3006, today we get an error on CLI version 6.0.0.4432. Yesterday the tasks were v2.0.0, today the tasks have version 2.1.0

If today we run v2.1.0 and set the Scanner CLI version to use to 5.0.1.3006 it works. If we leave this value empty, it fails (using 6.0.0.4432).

Strangely enough, there are no issues when using Microsoft hosted agents. We have this issue on our on-premise agents, running behind a proxy firewall. We use a service connection, token verifies successfully.

Integrated with MSBuild does not cause an issue. This issue only seems to occur when using the standalone option.

Has anything changed in this area?

08:43:07.016 INFO  Project root configuration file: NONE
08:43:07.032 INFO  SonarScanner CLI 6.0.0.4432
08:43:07.032 INFO  Java 17.0.11 Eclipse Adoptium (64-bit)
08:43:07.032 INFO  Windows Server 2019 10.0 amd64
08:43:07.032 INFO  SONAR_SCANNER_OPTS=-Dhttps.proxyHost=XXX.YYY.ZZZ -Dhttps.proxyPort=0000 -Xmx4096m
08:43:07.063 INFO  User cache: S:\_w\SonarCache\cache
08:43:07.836 INFO  JRE provisioning: os[windows], arch[amd64]
08:43:09.158 INFO  Communicating with SonarCloud
08:43:09.929 INFO  Starting SonarScanner Engine...
08:43:09.929 INFO  Java 17.0.11 Eclipse Adoptium (64-bit)
08:43:11.023 INFO  Load global settings
##[error]08:43:31.163 ERROR Error during SonarScanner Engine execution
java.lang.IllegalStateException: Unable to load component class org.sonar.scanner.bootstrap.GlobalConfiguration
	at org.sonar.core.platform.ComponentContainer$ExtendedDefaultPicoContainer.getComponent(ComponentContainer.java:52)
	at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:632)
	at org.picocontainer.parameters.BasicComponentParameter$1.resolveInstance(BasicComponentParameter.java:118)
	at org.picocontainer.parameters.ComponentParameter$1.resolveInstance(ComponentParameter.java:136)
	at org.picocontainer.injectors.SingleMemberInjector.getParameter(SingleMemberInjector.java:78)
	at org.picocontainer.injectors.ConstructorInjector$CtorAndAdapters.getParameterArguments(ConstructorInjector.java:309)
	at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:335)
	at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:270)
	at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:364)
	at org.picocontainer.injectors.AbstractInjectionFactory$LifecycleAdapter.getComponentInstance(AbstractInjectionFactory.java:56)
	at org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:64)
	at org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:91)
	at org.picocontainer.DefaultPicoContainer.instantiateComponentAsIsStartable(DefaultPicoContainer.java:1034)
2

Hey Richard!

I’m pretty sure this has to do with the Scanner CLI v6.0 moving over to using a sonar.scanner.javaOpts analysis parameter instead of a SONAR_SCANNER_OPTS environment variable (although I guess according to the docs you can use SONAR_SCANNER_JAVA_OPTS now). In your logs, it’s clear you’re using SONAR_SCANNER_OPTS to pass proxy information.

  1. I am personally confused by what happened to SONAR_SCANNER_OPTS and if it should still be backwards compatible, and I’m going to follow up on this
  2. You can keep using v5 of the scanner, or migrate to using either the new analysis parameter or environment variable.
4

Hi Colin,

Your reply is much appreciated. We would be very in favor of keeping the environment variable simply because our build servers are used by many teams and we do not want to bother them with proxy settings. Having over 300+ projects in SonarCloud it would be quite an administrative job.

5

Hey @zaat!

I understand. My last message got garbled a little while I was adding a link (I’ve went back and updated it) The good news is you can still use an environment variable, but it has changed: SONAR_SCANNER_JAVA_OPTS

I guess you’d have to put both while everyone makes the transition over to v6.

Ideally (according to me) SONAR_SCANNER_OPTS would still work, but we would warn that it’s deprecated. I’m poking around on that.

2 Likes
6

Hi Colin,

I can confirm, adding SONAR_SCANNER_JAVA_OPTS with the same value as SONAR_SCANNER_OPTS did the trick. Works for all our test runs. Thank you for the quick response. We will keep both environment variables on our server, with equal content.

Kind regards,
Richard