SonarQubePrepare configFile vs extraProperties, which one takes precedence

[copdips (Xiang ZHU)]

Hello,

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

[copdips (Xiang ZHU)]

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 sonar-project.properties) to add extra settings or replace the existing ones in extraProperties

  - task: SonarQubePrepare@5
    inputs:
      SonarQube: xxx
      scannerMode: 'CLI'
      configMode: 'file'
      configFile: sonar-project.properties
      extraProperties: |
        sonar.projectKey=xxx
        sonar.projectName=xxx
        sonar.projectVersion=xxx
        k=v

[ganncamp (G Ann Campbell)]

Hi,

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.

 
HTH,
Ann

[copdips (Xiang ZHU)]

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 sonar-project.properties 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.