Thom LambandClaude Opus 4.7
8def714683
SonarQube Analysis / sonarqube (pull_request) Successful in 4m23s
The Gitea Actions sonarqube workflow was running `dotnet build` and sonarscanner begin/end without ever invoking `dotnet test`, so Sonar was reporting coverage = 0% on the server despite a 1180-test suite already exercising the code locally. `scan-sonar.ps1` (the local equivalent) has had the coverage flags + test step the whole time — this aligns CI with it. Changes: - `sonarscanner begin` now passes `/d:sonar.cs.opencover.reportsPaths="tests/**/TestResults/**/coverage.opencover.xml"` so the scanner picks up the per-project OpenCover reports coverlet emits, and `/d:sonar.coverage.exclusions="tests/**,**/*.Tests/**"` so the tests themselves don't count toward the coverage denominator. - The dormant step 8 (a disabled `if: false` curl-debug block from an earlier auth-troubleshooting session) is replaced with the actual test run: `dotnet test ... --no-build --settings coverlet.runsettings --collect "XPlat Code Coverage"`. - Step 9 (`sonarscanner end`) unchanged — it now has coverage data available to upload. Once this lands, the next scan will surface the *real* coverage number for sql-utilities. Until we see that number we don't know which files actually need test investment vs. were already covered by the existing suite. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>