Dotnet-sonarscanner 9.0.2 breaks scans - 9.0.1 works fine

[fbraun4358 (Florian Braun)]

Must-share information (formatted with Markdown):

• Using dotnet-sonarscanner 9.0.2 installed via dotnet tool update dotnet-sonarscanner
• Running the scan in a GitHub Action, docker runner. Java and dotnet were set up via their respective setup actions directly from github.

The dotnet-sonarscanner is installed via

mkdir -p .sonar/scanner
dotnet tool update dotnet-sonarscanner --tool-path .sonar/scanner
echo "[runner/working/directory]/.sonar/scanner" >> $GITHUB_PATH

The working directory in the runner is the base repo directory after doing a simple actions/checkout run. Everything is run from within this root directory of the repo.

Workflow is as follows:

First, set do the begin on the scanner:

dotnet-sonarscanner begin /k:"[name]" \
    /s:"[runner/working/directory]/SonarQube.Analysis.xml" \
    /d:sonar.token=$SONAR_TOKEN \
    /d:sonar.buildbreaker.skip=true \
    /d:sonar.qualitygate.wait=true \

SonarQube.Analysis.xml contains:

<SonarQubeAnalysisProperties  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.sonarsource.com/msbuild/integration/2015/1">
    <Property Name="sonar.cs.opencover.reportsPaths">**/TestResults/**/coverage.opencover.xml</Property>
    <Property Name="sonar.host.url">[on-prem URL]</Property>
    <Property Name="sonar.projectBaseDir">.</Property>
    <Property Name="sonar.projectKey">[project key]</Property>
    <Property Name="sonar.qualitygate.wait">true</Property>
    <Property Name="sonar.verbose">false</Property>
    <Property Name="sonar.exclusions">.github/actions/**/*.js</Property>
</SonarQubeAnalysisProperties>

Then we run a build and test with dotnet test [solution]

Finally finishing the scan with dotnet-sonarscanner end /d:sonar.token=$SONAR_TOKEN

With version 9.0.1, the call to end processes as expected, with version 9.0.2, we get this error for every file in solution which was being scanned:

15:38:23.418  WARNING: File '[runner/working/directory]/src/Component/File1.cs' is not located under the base directory '[runner/working/directory]/.sonarqube' and will not be analyzed.
15:38:23.418  WARNING: File '[runner/working/directory]/src/Component/File2.cs' is not located under the base directory '[runner/working/directory]/.sonarqube' and will not be analyzed.
15:38:23.418  WARNING: File '[runner/working/directory]/src/Component/File3.cs' is not located under the base directory '[runner/working/directory]/.sonarqube' and will not be analyzed.
15:38:23.418  WARNING: File '[runner/working/directory]/src/Component/File4.cs' is not located under the base directory '[runner/working/directory]/.sonarqube' and will not be analyzed.
...
15:38:23.422  Generation of the sonar-properties file failed. Unable to complete the analysis.
15:38:23.425  Post-processing failed. Exit code: 1

It seems that what sonar.projectBaseDir is pointing to in 9.0.2 has changed vs 9.0.1. This seems like a bug for a patch release IMO. In 9.0.1 it is pointing at the directory in which begin call was made, in 9.0.2 it appears to be the tool directory.

[Colin]

Hey there.

Thanks for the report. We just released this today, so I’ve sounded some alarm bells. In the meantime, keep using 9.0.1 if you’re running into issues.

[denis.troller]

Hey,

May I ask what happens if you remove the <Property Name="sonar.projectBaseDir">.</Property> entry from the configuration file?

Denis

[fbraun4358 (Florian Braun)]

Thanks for the quick reply. Yeah, we have a test environment where we don’t pin our tools to a specific version, so we always get the latest. I noticed the failures this morning, and saw the version update happened so wanted to report ASAP

Denis, Let me run a couple of tests.

[fbraun4358 (Florian Braun)]

Ok, so I ran a couple of tests, I removed the sonar.projectBaseDir from the xml file and ran with 9.0.1 and 9.0.2. Both work as expected.

Looking at our history, it looks like the property was added to the file 8 months ago, we were migrating from an out of date version of 5.7.2 to 6.2.0 at the time.

Looking at the PR and the commits, it looks like the reason for adding the relative path was “IDK why, but without this it is failing”

[fbraun4358 (Florian Braun)]

So I ran one more test, running with 9.0.2 and this time adding back the property and setting it to ./.. since it appears to be working relative off of the tool location and not the working directory for 9.0.2.

For this test, the files were all found and scanned, but as a PR, it counted all the files in the repo as new, not just the files changed in the PR.

[gregory.paidis]

Ok, so I ran a couple of tests, I removed the sonar.projectBaseDir from the xml file and ran with 9.0.1 and 9.0.2. Both work as expected.

Hey @fbraun4358 , thanks for the confirmation that it worked.
From what I can tell, this solves your issue, as you were trying to set the projectBaseDir to the current working directory, which was the default behavior with or without the flag.

You are right that relative paths are not respected, and I understand it is frustrating that the hotfix release broke your previous behavior. The main point was that it never worked, but there was another issue were the projectBaseDir was calculated ONLY from the CLI parameters, ignoring the global file. So by fixing one issue, this one came up .

I made a ticket in our backlog to track this, but since you can keep working without the property at all, if you don’t see any other problems, feel free to mark this as the solution.