Azure Devops with our own build & deployment agents on our Azure hosted VM’s, SonarQube Enterprise Edition 10.7 running on Azure hosted VM (Windows Server 2019).
Using the latest SonarQube extension (7.0.3) v7 tasks in our builds with ‘Integrate with .NET’ I want to disable JRE auto-provisioning globally. We want to use the installed JRE because this is configured for our own certificates (we use our own CA)
With v6 tasks and ‘Integrate with MSBuild’ the installed JRE is used.
With v7 tasks and using sonar.scanner.skipJreProvisioning=true the installed JRE is used. However we have hundreds of builds and it is no solution to modify every one of these.
Hi there, @droos_rdw and welcome to the community.
There is no global flag to disable JRE provisioning, no.
We are aware of the difficulties with private certificates and are working on a solution for the Scanner for .NET. Unfortunately, I do not have a timeline yet for the solution.
Just to make sure, since you are using the Scanner for .NET, I imagine your certificates are installed in the OS trust store?
Thanks for the update.
Yes on “your certificates are installed in the OS trust store”.
So this is regarding the SonarScanner CLI. It would be nice if an (environment) option could be added for the Scanner for .NET to not use auto-provisioning. The logic for finding and using the installed JRE is working fine.
For the time being I will advise our developers to continue using the v6 tasks (and ignore the deprecated warning)
I want to thank you for your patience on this one. We have the certificates problems lined up as one of the first topics we will tackle after the end-of-year break.
Rest assured we are fully aware this is a blocker for many of you and we will find a way to address it.
Is using On Premises SQ with a self-signed certificate really so unexpected that you never thought about this use case before implementing the new feature?
Is this really a new idea? I usually expect a product to be built with the customer in mind…
We also encountered this issue. After some debugging it looks like the task uses the jre provided by SonarQube itself. Even with all the necessary prerequisites set.
If you want a workaround for now:
Replace the cacerts file in the SonarQube ‘jres’ folder in the JDK archive you are using for your pipeline agents. We’re using Windows, so the location is as follows:
sonarqube-2025.1.0.102418\jres\OpenJDK17U-jre_x64_windows_hotspot_17.0.13_11.zip\jdk-17.0.13+11-jre\lib\security\
We’re using private CA’s which are automatically added to the installed Java keystore, so it was just a matter of copying the modified cacerts to the archive above.
It’s unfortunate that this seems necessary, a simple environment variable or java_home check would have sufficed from SonarQube’s side.