When using sonar cloud plugin for azure devops with a hosted agent (win 2019) Machine specs the default (1.8.0) java version is used. But other versions are also installed on the same agent (see machine specs)
The following warning is shown:
##[warning]WARN: The version of Java (1.8.0_222) you have used to run this analysis is deprecated and we will stop accepting it from October 2020. Please update to at least Java 11.
Would it be possible in the case of a hosted agent, that the proper version can be used?
I think we’re going to need a better solution than using a hard-coded path to the JRE. That’s going to change “randomly” when MS updates the build agents - which would suddenly break builds. I know this isn’t entirely in your hands, but is there a way to suppress the warning for now? It’s decorating every PR build, and the ideal solution here is for MS to change the default version of the JRE.
This would be a workable solution if you have to maintain a couple of pipelines but in the case of 100+ pipelines then this is not the right solution. On the other hand, by doing this you now depend on a very specific build agent with the given path.
It would be better if sonarqube/sonarcloud scanner could use the a given java path or check if JAVA_HOME_11_X64 is set.
The warning itself is also weird in that the requirements of sonarqube scanner states that it is supported sonar qube requirements and that java 1.8 is still supported until december 2020. I do agree that it would be nice if this warning can be suppressed.
I don’t see why Microsoft should change the default on a supported Java version, it would be nice if we could choose the default java version. That is a different story, and I am also working on that on the Microsoft forums.
Same as Colin’s solution is that this would work if there are only a couple of pipelines to maintain, but if you need to maintain 100+ pipelines that you first need to add all those task and when Microsoft upgrade the java version, then the clean solution would be to delete all those tasks.
Same as Jacob, I have about a 100 pipelines that need to be altered if I were to go with either Colin or Chris’s solution. I think that a pipeline extension like SonarCloud’s shouldn’t be reliant on these kinds of work arounds for the most common scenario.
Also, I find posting a comment in a pull request somewhat intrusive for a message like this. But that is just my personal opinion and you can do with that what you will.
Same here. Many build definitions from many teams. Would be great if we don’t have to update all of them (would feel weird for teams using MSBuild to have to add Java settings in their build definition).
My suggestion: Can SonarSource discuss this with Microsoft, and once Microsoft has updated their environments, then automatically upgrade the sonarscanner, and leave us users out of that discussion?
In my opinion, the marketplace tasks provided by Sonar should automatically use the correct Java version. It is already installed on the image, so why can’t you just use it?
It should be the tasks responsibility to look for the correct version, not the users to point the task to the correct version.
As i do agree that sonarcloud should fix this, I have also created a feature request on the Microsoft side for letting us choose what the default java version should be feature request choosing java version on hosted agend.
Even we are facing the same issue. As of now we have over 25 pipelines. Now for all the Pull Requests this is posted as an warning. Until an action is taken on this, it is stopping the developers from merging the code.
Even I believe that the SonarCloud Analysis task should be able to identify weather the required Java version is installed or not.
Thank for your feedback. We will have a look on what we can do to improve this. The idea was to really warn the users, and we know that Hosted agent are still stuck on Java 8 by default. Here a summary post that explain the reasons : SonarCloud scanner environment soon to require Java 11+
The problem is that if we force Java 11 to be used, some of the users will not be able to build anymore their solution (like Xamarin) and that’s not what we want indeed. So we’ll need to find a solution that fit everybody’s need. Hope you’ll understand.
The problem is that if we force Java 11 to be used, some of the users will not be able to build anymore their solution (like Xamarin) and that’s not what we want indeed. So we’ll need to find a solution that fit everybody’s need. Hope you’ll understand.
I am confused by this.
Seems like it would be possible for your task to search for known locations of the preferred Java version and if it finds it, use that.
This is exactly how several Microsoft tasks work. For example, the Nuget task. It searches known locations for the required version and uses it if found.
I am not seeing how doing this would impact other aspects of you build. You are simply specifying the Java version being used by your tasks. Other tasks can use any version of Java they like…
Unless I’m missing something?
In the short term, you really need to remove the comment that is added to every PR. It really messes up our workflow. We can no longer auto-complete PRs.
