Version 4 and 5 diff of Azure Devops extension

We use AzureDevops extension always version 4 in our build pipelines which since a couple of weeks is not communicating correctly with sonarQube server. A technician indicated that we should migrate to version 5 of the extension.
The question is there abig difference in term of configuration etween 4 and 5?
Thanks

Hi,

The current version of that extension is 5.8. You should upgrade at your earliest convenience.

The version summaries (click ‘Show more versions’) in the docs should help.

 
Ann

1 Like

Thanks Ann, I would like to undersatnd if any incompatibility exists between 5 and 4
we have piplines configured to use version 4 (almost 50 .net and java projects), I would like to know if something will break, if I switch to version 5 please as I remember there was some features which disappearded from verion 4 that they were available in version 3

Hi,

Check the version notes.

 
HTH,
Ann

Ann where ae the relase notes, I click on any link I get, do you mean this? If yes there is absolutly no release notes

1 Like

Thanks Volker, can you please read my thread (1st 4 lines) here at View SonarQube full analysis report in the build summary in Azure DevOps - SonarQube - Sonar Community (sonarsource.com)

It seems that there was an interesting config in version 3 which seems disappaerd in version 4 and 5 of the extension or maybe it is somewhere else.

Hi Salam, I’m not an employee of SonarSource.

As you are not using an yaml pipeline (but instead the older UI configured Azure pieline) I have no up-to-date experiece with your case. The parameter /s is IMHO for the case of an existing sonar-properties file in the repo. I assume you pass all parameters with the UI task and especially in the extra arguments and doesn’t have a committed properties file. That assumed, you’ll propably don’t need the `/s/ argument.

If I need a “full analysis” then I start a analysis of the branch - or there are even harder options:

  • Use a separate key for the branch - in SonarQube it should then be non-related to the existing analysis. Don’t forget to delete later on the extra project from SonarQub (it counts to the number of lines of your license)
  • Set the branch for your fill analysis in the project settings in SonarQUbe as main branch. Yes, this is dirty cheating and NOT remoonded. But you should get the full analysis in SonarQube.

Thanks again Volker, I have both yaml and classic pipeline which acieve the same thing exactly same config but one in he classic UI as you indicated the 2nd pipelne is in Yaml.

I have in the repo sonar-project.porpertiesfile as follows

and here isa copy in the Yaml file

Show can this help in achievng what I am looking for and have the analysis inside the build smary?
Thanks again

@eliassal I never used a committed sonar.properties file up to now. Therefore no experience at all with that.

If projectKey and projectName are identical, you can omit the projectName. The default is to take the projectKey.

The yaml tasks seems ok for me. You can shortcut the task name to SonarQubePrepare@5.
Usually I put the Microsoft Code Coverage property to: sonar.cs.vscoveragexml.reportsPaths=$(Agent.TempDirectory)/**/*.coveragexml
Another input I’m using is projectVersion: '$(Build.BuildNumber)'.
Otherwise I can’t see any real deifference to my usage. Sorry that I can’t help.

1 Like