JAVA_HOME for SonarQube extension for Azure DevOps

We use SonarQube extension version 4.11.0 for Azure DevOps Server from the Market place

The “Run Code Analysis” tasks has internal demand encoded into it and requires “java” capability to exist on the agent (Github)

However, what you really depend on is the “JAVA_HOME” environment variable (Github)

Would it make sense to amend the task and put standard well-know “java_home” instead of “java” as a demand?

Hi @a1exstr,
I’d like to know more about your context and the reason of this feature request. What is your problem behind that? Do you use self-hosted agents? If so, which one? Is it a pain to have to set the env variable?

Thank you.

Hi @Christophe_Havard,
Thank you for your response.
We use self-hosted windows agents and install OpenJDK on them. Typically, the JDK comes with JAVA_HOME environment variable and you don’t have to do anything else. It just works.
With additional “java” demand one would have to create this capability or environment variable manually. It seems to be a non-standard variable. Obviously, it is not a pain to automate an agent provisioning and incorporate the variable there, but it means additional effort and investigation on “why the task fails, when java is installed on my system”. Then you just realize that there is just a specific demand added by a task and you need to address it.
Ideally, if something requires java (or anything else), it should work out of the box when java is installed with default values.
Currently, the extension does not explain its pre-requisites and it is not that obvious, that it will add “java” to demands for classic pipelines.

Ha, so it’s Microsoft powershell script from <agent_home>\bin\powershell\Add-JavaCapabilities.ps1, which adds the ‘java’ capability based on JRE or JDK it was able to find on the system. And seems you rely on this agent startup behavior :slight_smile:
Makes sense then why you demand ‘java’
I guess I’ll just add ‘java’ environment variable for OpenJDK installation.

Hi @a1exstr,
Yes you found it! :slight_smile:
That’s what I’ve been explained by our engineering team, that we rely on a Microsoft’s script and it’s a limitation from their side. Moreover, there seems to be a “bug” from them that has never been addressed.
Anyway thank you for your feedback, we will document this very (very) soon :wink:


This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.