Hi, GitHub suggests this is the correct place to highlight issues for the dotnet-sonarscanner apologies if it isn’t.
I have a .NET project that has a GitHub action configured to run the dotnet-sonarscanner similar to how Colin has outlined in this separate thread which is triggered on each pull request and inline-lints the code under the Files Changed tab. We’ve noticed 2 issues that only seem to happen with the dotnet-sonarscanner specifically.
The first is when using Colins example this renders the SonarCloud warnings twice per violation. It appears to be caused by the sonar begin stage starting a listener then as the dotnet build parses the project the scanner detects the inline warnings as they are thrown. After the build succeeds it shows the same errors again in a summary table at the end by default which are re-computed by Sonar. We have applied a fix/workaround for this in the project by adding /clp:NoSummary to the dotnet build. Ideally clashing errors should be handled by the scanner.
The second issue is the //NOSONAR flag appears to be ignored by the dotnet-sonarscanner. We’ve manually triggered a scan and SonarCloud does ignore these blocks as expected so the issue appears to be isolated to the dotnet-sonarscanner. We haven’t found a work-around for this, only suggestions to omit the full file from the scan which is counterintuitive.
This screenshot of the output in GitHub should hopefully illustrate the issue.
Uhm, I’m fully familiar with the GitHub UX and Roslyn integration with static analysis - is GH showing the warnings based on the build logs?
I’m not really clued up with the tools used under the hood but the general gist is yes, if the build log reports an error twice it - GitHub will show the same error twice on the same line (see the screenshot above). It would be handy if the Scanner could detect duplicate warnings for a line and only report them once.
these issues are ignored when being uploaded to SonarCloud. Not during the build. So they will appear in the build logs. If that’s what you mean.
In this case is there an alternative method to add a single exception? In the screenshot above it’s warning that the CORS policy is too permissive however due to the nature of the system we can’t restrict this any further so suppressing the warning would be ideal.
