Fix the real Sonar LOW issues and make the Uno exclusion actually apply - #11
Merged
Conversation
All 62 open SonarCloud issues were LOW, but 61 of them were false positives that cannot be fixed in code. The cause is server-side: Automatic Analysis is still enabled (sonar.autoscan.enabled=true), so every sonarscanner end step is rejected and sonar.yml has never published an analysis. The results on SonarCloud therefore come from a mode that never builds, which is why the Uno app drew 57 bogus S2325 "make it static" findings (every read of an [ObservableProperty]-generated property, every IValueConverter member) and 4 S8970 "nullable warnings are disabled here" although Directory.Build.props sets <Nullable>enable</Nullable>. Applying any of them would not compile. The same conflict makes every /d: setting in sonar.yml inert, including the Source/Trackify/**/*.cs exclusion added in #10 — which is why those findings never closed. Mirror that exclusion into .sonarcloud.properties, the file automatic analysis actually reads, so it takes effect in the mode that is running today and stays correct after the switch is flipped. Genuine fixes, verified with SonarAnalyzer.CSharp 10.31.0.145097 run locally over the analysed scope (now clean): - S3878 in LwpAddressingMapping.ParseMacAddress. The suggested fix is a silent bug: Split(':', '-') binds to (char, int count) because '-' converts to int, so the '-' form would stop parsing. Use the non-params (char[], StringSplitOptions) overload, which satisfies the rule and keeps the behaviour, and add tests covering both separators. - S1144 unused Domain constant in LayerTrainDependencyTests. - S8969 redundant null-forgiving operator after Assert.NotNull. The last two are not reported today (Test/ is only analysed by the CI scan) but would surface the moment it starts publishing. Document the conflict as R-9 and the local analyzer procedure in arc42 7.6. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
All 62 open SonarCloud issues were LOW, but 61 of them were false positives that cannot be fixed in code. The cause is server-side: Automatic Analysis is still enabled (sonar.autoscan.enabled=true), so every sonarscanner end step is rejected and sonar.yml has never published an analysis. The results on SonarCloud therefore come from a mode that never builds, which is why the Uno app drew 57 bogus S2325 "make it static" findings (every read of an [ObservableProperty]-generated property, every IValueConverter member) and 4 S8970 "nullable warnings are disabled here" although Directory.Build.props sets enable. Applying any of them would not compile.
The same conflict makes every /d: setting in sonar.yml inert, including the Source/Trackify/**/*.cs exclusion added in #10 — which is why those findings never closed. Mirror that exclusion into .sonarcloud.properties, the file automatic analysis actually reads, so it takes effect in the mode that is running today and stays correct after the switch is flipped.
Genuine fixes, verified with SonarAnalyzer.CSharp 10.31.0.145097 run locally over the analysed scope (now clean):
The last two are not reported today (Test/ is only analysed by the CI scan) but would surface the moment it starts publishing.
Document the conflict as R-9 and the local analyzer procedure in arc42 7.6.