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
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:
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
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
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.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.