Scope Sonar analysis to the workspace, narrow workflow permissions

[matt-edmondson]

Summary

Three CI fixes. Nothing in the tool itself changes.

The quality gate on #66 failed on reliability and security ratings that had nothing to do with that PR's code, and the run log was full of warnings belonging to KtsuBuild. Both turned out to have the same root cause.

Build KtsuBuild before the SonarQube window opens

SonarScanner injects its Roslyn analyzers into every project compiled between begin and end. The workflow cloned and built KtsuBuild inside that window, so roughly 25 of KtsuBuild's own code smells (S1192, S3776, S107 and friends) were reported as warnings against this repository, and the scanner indexed KtsuBuild.CLI and KtsuBuild as modules of this analysis:

INFO: Indexing files of module 'KtsuBuild.CLI'
INFO: Indexing files of module 'KtsuBuild'
INFO: Indexing files of module 'IconHelper'

Those are compiler diagnostics rather than reported issues, so sonar.exclusions could never suppress them. The pre-existing **/KtsuBuild/** entry had no effect on them at all.

The clone now happens before begin, a new step compiles KtsuBuild.CLI there, and the pipeline step runs it with --no-build so nothing is recompiled inside the window.

Pin sonar.projectBaseDir to the workspace

Scanner for .NET v8 derives the base directory from the projects it sees. A project compiled under the runner temp directory widened it to the common ancestor of the workspace and that directory, which pulled the runner's own action checkouts under _actions into the file scan. That is what actually failed the gate: the reliability rating was driven entirely by a bug in merge.test.ts, which belongs to actions/checkout, and four other TypeScript files from the same source contributed code smells.

With the base directory pinned, only this repository is ever in scope. That makes the _actions, _temp and KtsuBuild exclusions all unnecessary, so the Configure SonarQube exclusions step is deleted. sonar.exclusions keeps only NativeExports.cs, a genuine in-repository exclusion, passed inline like the coverage exclusions already were.

Narrow update-sdks.yml permissions

The workflow declared permissions: read-all, which SonarCloud flagged as a vulnerability and which drove the security rating. The default is now contents: read. The one job that writes already declares the contents: write and pull-requests: write it needs, and job level permissions override the workflow default, so behaviour is unchanged.

Shells

Every step across these workflows now uses pwsh, replacing a mix of bash, Windows PowerShell and pwsh. The converted steps do no redirection into GITHUB_ENV or GITHUB_OUTPUT, so the UTF-16 versus UTF-8 encoding difference between Windows PowerShell and pwsh does not apply to any of them. The two steps that do write there were already pwsh and are untouched.

Test plan

Verified locally where possible:

• dotnet build then dotnet run --no-build against the real KtsuBuild.CLI, confirming the CLI runs without recompiling
• The rewritten tag selection sorts by [version] rather than as text, so v1.8.15 beats v1.8.9. The bash and pwsh versions were run side by side and both selected v1.8.15
• The rewritten clone step performs a real shallow clone of v1.8.15 with the CLI present
• All three workflow files parse, and no non-pwsh shell remains

What to check on this run

The base directory behaviour only manifests under a real scanner run, so this PR is its own test. In the End SonarQube step, look at the Indexing files of module lines:

• Only IconHelper and IconHelper.Test means the diagnosis holds
• KtsuBuild still appearing means --no-build is not taking effect
• _actions files still being flagged means projectBaseDir is not being honoured

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ruh9nAQiuU5VGHV8uJCXtu

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud