SonarQubePrepare configFile vs extraProperties, which one takes precedence


I’m using the task SonarQubePrepare@5 in Azure DevOps, could you please confirm which one takes precedence for the same settings defined in both:

  • configFile
  • extraProperties

it seems that it’s extraProperties which takes precedence.
Is it possible to add an option to the task that we can ask configFile to take precedence ?

In that way, we can set default global settings in extraProperties, and let each repo to add its own configFile (the file to add extra settings or replace the existing ones in extraProperties

  - task: SonarQubePrepare@5
      SonarQube: xxx
      scannerMode: 'CLI'
      configMode: 'file'
      extraProperties: |
1 Like


The precedence is laid out here in the docs. The extraProperties are counting as commandline arguments, so they’re always going to override everything else.

With that in mind, I would flip your model: set global properties in the SonarQube.Analysis.xml file and do project-specific overrides in extraProperties.


Hi ganncamp

Thanks a lot for the comfirmation and suggestions.

But in practice, as I use the task: SonarQubePrepare@5 in a shared Azure pipeline template, it’s much easier to defined some global default settings in extraProperties at shared template level, and let the developers to add project-specific overrides in the file saved in their repos.

I think it would be the same need for Sonar in Github Actions.

But I can understand well that for the Sonar product itself or most of other tools, the command line arguments have always the top priority as a good design pattern.

Maybe Sonar can introduce a third config option sth. like defautProperties.

1 Like

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