Azure DevOps: SonarCloud Prepare Analysis Configuration task ignores selected organization when fetching quality profiles


(Tim Waalewijn) #1

Versions used

  • SonarCloud (api/server/version result)
  • Azure DevOps SonarCloud Extension 1.5.1
  • MSBuild scanner (whichever version is used by the SonarCloud extension)

Error observed

I’ve created a new private organization to test if I could move my organization’s SonarQube installation into SonarCloud.

After modifying a copy of the C# Sonar way profile, activating a few extra rules we use for our projects, setting up a project to use said profile and running an analysis through my test Azure DevOps pipeline I noticed the rules I activated weren’t being used.

For the rest of the bug report I’ll refer to this organization and project as myorg and myproject respectively.

Checking the logs of the pipeline showed me that the scanner first tried to get the quality profiles for my project using an api call:

Fetching quality profile for project 'myproject' from

Following that link showed me a JSON response containing an error:

  "errors": [
      "msg": "Component key 'myproject' not found"

The log then shows that the scanner is fetching the default profiles, which I assume is a fallback for when the project’s profiles cannot be found:

Fetching quality profile for project 'myproject' from

It then states that rules were being fetched for the ‘cs-sonar-way-31865’ profile, which is not the one I assigned to the project, and then uses those for the Roslyn ruleset.

Looking at the MSBuild SonarScanner source code I found out that the begin command accepts an optional argument /o: to specify the organization.

This value then later gets added to the api call here.

Modifying the earlier api call from the log to what the scanner would use when this value is provided did indeed retrieve a result for my modified quality profile:

The command that the Prepare Analysis Configuration task performs to start the scanner looks like this in the log:

SonarScanner.MSBuild.exe begin /k:myproject

Looking at the Azure DevOps extension source code it looks like this argument is indeed not being added.

The end result being that the extension does not pass on the selected organization to the scanner and it ends up using the default quality profile because it could not find one for the project.

Steps to reproduce

  • Create a new (private) organization
  • Derive a C# quality profile from Sonar way.
  • Activate a new rule on it e.g. S103
  • Create a new project inside the organization and set it up to use the derived quality profile
  • Run the analysis in an Azure DevOps pipeline using the SonarCloud extension
  • Log should be similar to the full_log one I’ve uploaded which means the default C# quality profile was used.

full_log.txt (9.6 KB)


None that I know of.

Custom quality profile: overrided rules not reflected in SonarLint.xml file and are ignored in sonarcloud
(Tim Waalewijn) #3

Hi @Ammo ,

I noticed you’ve created an issue for this bug on the sonar-scanner-msbuild repository.

Thank you for that! :+1:

Since I’m still on a trial license and I wanted to continue my evaluation, I’ve created my own fix for this issue based on the vsts/azure devops scanner.
My fix being to pass the value of tl.getInput(‘organization’) as the value for the /o: / /organization: argument if a value exists for it.
I’ve deployed this version on my Azure DevOps organization as a test extension and can confirm that the scanner is properly retrieving the quality profile now.

I was going to submit this fix as a PR this weekend (still need to create a GitHub account etc.) but now I’m questioning if that is still necessary as it now looks like this issue was supposed to be fixed in the scanner instead?

I’d appreciate your thoughts on this matter.

(Duncan Pocklington) #4

Hi @twaalewijn,

Thanks for the detailed investigation, and for the pull requests to SonarCloud Azure extension and the Scanner for MSBuild.

We’ve had a discussion internally about whether the bug is in the scanner or the SonarCloud Azure extension, and we think long-term fix is should be on the scanner side. However, that is going to take us a bit longer to fix, so our plan is as follows:

  • merge your PR to the SonarCloud Azure extension (now tracked by this bug)
  • release new versions of the Scanner for MSBuild and the SonarCloud Azure extension on Monday

We’ve also created bug #699 against the Scanner for MSBuild for the longer-term fix to the parameter handling on the scanner side.

Separately, you’ll have seen that I’ve merged your PR to make the scanner error if the organization is specified using /d:sonar.organization... on the command line.

Thanks again,

(Duncan Pocklington) #5

Update: v1.6.0 of the SonarCloud Azure DevOps extension was released yesterday. It should now respect the organization when selecting the Quality Profile to use.


(Tim Waalewijn) #6

I’ve updated the extension and can confirm that this issue is now fixed.
I’ll be moving to SonarCloud next week.

Thanks @duncanp and the rest of the SonarSource team for helping with the fix :+1:.

@DGUCOM I hope it works for you now as well!