I would like to use file configMode in my Azure DevOps pipeline, mainly to exclude external library code but cannot seem to get it to recognize config files of any kind. I do not want to use the UI or pipeline .yaml file to specify the exclusions as only some developers have access to these locations.
I have tried both the SonarQube.Analysis.xml format (which worked fine when I tested the self hosted SonarQube version), and the sonar-project.properties format outlined elsewhere and neither file type seems to work. The only mention of configuration in the log output is this:
You can’t combine a scannerMode of MSBuild with a configMode. While you can pass a SonarQube.Analysis.xml file to the Scanner for .NET when running it without the extension (/s:<custom.analysis.xml>) this isn’t supported by the extension for Azure DevOps.
Can you clarify what you mean by developers not having access to the pipeline .yaml file? Isn’t it checked in with your codebase?
Yes but it is the responsibility of the devops team to maintain, as are the sonarcloud project settings, so they are restricted only to that team. I want to be able to specify a config file in order to avoid unnecessary collaboration between the devevloper and devops teams whenever a new exclusion has to be added e.g. when a dev adds some library code.
I had assumed there would be some way to specify a file as in the SonarCloud Extension for Azure DevOps documentation it says “The extension embeds its own version of the SonarScanner for .NET”, which does indeed allow you to specify a SonarQube.Analysis.xml file.
I will just revert to running the scanner manually in the pipeline if using a config file is not possible with the Azure DevOps extension as this feature is too important not to have.
Wow, I just lost so much time trying to figure out why my sonar-project.properties weren’t picked up. This really should be clearer in the documentation!
That said, are there any plans for automatically converting the .properties file to the XML format expected by the MSBuild scanner in the future? It would be easier to streamline configuration instead of “hiding” it in csproj files…