JAVA_TOOL_OPTIONS setting in Azure DevOps causes "failure"

I get an error when I execute “Run Code Analysis” in an Azure DevOps pipeline

“##[error]Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8”

This output causes the element to “fail” in the pipeline, even if execution is successful.

SonarQube plugin for Azure DevOps (formerly VSTS), version 4.6.0
The agent is operating in a Kubernetes environment based on Ubuntu.
JAVA_TOOL_OPTIONS is not set by our pipeline implementation, it’s coming from Microsoft.
Sonar runner’s execution causes a “Picked up …” message to STDERR (feature of Java runtime!)
I have a “Run Code Analysis” block in the pipeline
I see no potential workaround: right now. I see no option to remove JAVA_TOOL_OPTIONS from the pipeline’s environment.

Is it possible to provide a plugin update where this error output is redirected so that the DevOps agent does not classify the output as error?
Any other solution?

Thanks
Jörg

Any update on this ? I am facing exactly the same issue.I am on version 4.9.0

I’ve just started seeing this in my Linux builds in Azure DevOps too. Debug from my SonarQubeAnalyze task in my build on an ubuntu-18.04 Microsoft-hosted build agent:

##[debug] --from=ScannerAzureDevOps/4.11.0
/home/vsts/work/_tasks/SonarQubeAnalyze_6d01813a-9589-4b15-8491-8164aeb38055/4.11.0/sonar-scanner/bin/sonar-scanner -X --from=ScannerAzureDevOps/4.11.0
##[error]Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
##[debug]Processed: ##vso[task.logissue type=error;]Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
12:05:46.101 INFO: Scanner configuration file: /home/vsts/work/_tasks/SonarQubeAnalyze_6d01813a-9589-4b15-8491-8164aeb38055/4.11.0/sonar-scanner/conf/sonar-scanner.properties
12:05:46.106 INFO: Project root configuration file: /home/vsts/work/1/s/sonar-project.properties
12:05:46.148 INFO: SonarScanner 4.4.0.2170
12:05:46.148 INFO: Java 11.0.8 AdoptOpenJDK (64-bit)
12:05:46.148 INFO: Linux 5.3.0-1034-azure amd64

The build appears to pass but this annoying warning appears on the build summary page:

image

And the [Build succeeded] notification emails from Azure show it too.

The earliest build I’ve seen this issue in is on 13 August.

I get same error on ubuntu-20.04

Same issue here in Azure DevOps on ubuntu-latest.
Please do something about this incorrect error message

Starting: SonarQubeAnalyze
==============================================================================
Task         : Run Code Analysis
Description  : Run scanner and upload the results to the SonarQube server.
Version      : 4.11.0
Author       : sonarsource
Help         : Version: 4.11.0. This task is not needed for Maven and Gradle projects since the scanner should be run as part of the build.

[More Information](http://redirect.sonarsource.com/doc/install-configure-scanner-tfs-ts.html)
==============================================================================
/home/vsts/work/_tasks/SonarQubeAnalyze_6d01813a-9589-4b15-8491-8164aeb38055/4.11.0/sonar-scanner/bin/sonar-scanner --from=ScannerAzureDevOps/4.11.0
##[error]Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8

Can you change the docker image so that it doesn’t export that variable? Any java application will have that output to stderr.

SonarCloud – Can you fix the issue on your end, as this was not a problem a month ago, so something you all changed caused this new issue to pop-up.

Thanks.

If you take the time to read this topic you’ll find out that this is not caused by the scanner.
We are still evaluating whether we’ll find a way to suppress that particular output to stderr.

Hi,

we are using SQ plugin 4.23.1, Azure self-hosted agent with AdoptOpenJDK Java 11.0.11 and build fails with “Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=…” which is the only one “error”.

Since the output of “Picked up…” message into an error stream seams to be an unoverridable feature of Java, is there any workaround on SQ scanner side to “succeed” the build?

Thank you.

We’re annoyed by this as well, as we need to set proxy variables this way. Any solutions yet?