SonarSource
/s parameter behaving unexpectedly
Description
Providing the /s parameter to load a settings file is behaving unexpectedly, even when taking into account #424.
Repro steps
- Try launching the scanner with
dotnet sonarscanner /s:SonarQube.Analysis.xml /k:test - Results in
Unable to find the SonarQube analysis settings file 'D:\TeamCity\buildAgent\work\d0c8130a01b0ed62\.sonarqube\.sonarqube\SonarQube.Analysis.xml'. Please fix the path to this settings file.
- Try launching the scanner with
dotnet sonarscanner /s:.sonarscanner/SonarQube.Analysis.xml /k:test - Results in
Unable to find the SonarQube analysis settings file 'D:\TeamCity\buildAgent\work\d0c8130a01b0ed62\SonarQube.Analysis.xml'. Please fix the path to this settings file.
Expected behavior
I expected the first one to work as long as I put the file in .sonarqube, but somehow it pulls a different path when I provide a relative path.
Actual behavior
The first command should work in accordance with #424.
Known workarounds
Providing additional settings via other commandline arguments works, but is cumbersome.
Related information
- SonarScanner for MSBuild version: 4.7
- SonarQube server version: 7.9.1
- Languages in your solution: C#
@PhilippCh How is this different from #424? 424 says relative paths don't work, which seems to be what this ticket is saying too.
I have the same issue, using version 5.3.1 of the sonarscanner. I've tried multiple installations of the .NET Global Tool: --local --tool-path <path_within_my_project>
It looks like the dotnet sonarscanner ... is a proxy to the MSBuild tasks running at .sonarqube and the settings path location is checked first at the location of the dotnet-sonarscanner tool and then again at the location of the MSBuild tasks is this seems to be the reason why we see the messages indicated by @PhilippCh.
The workaround is to specify all settings via the command line but that is quite cumbersome. This issue was reported in 2019, so maybe it's time to get it fixed :)
CC: @DavidSSL
