ci: tolerate a SonarQube Cloud outage instead of failing the build

[matt-edmondson]

SonarCloud is a third party, and its scanner fails in pre-processing — before a single project is compiled or a single test runs. A total outage therefore turns every pull request red while saying nothing at all about the change under review. That is a false signal, not a quality gate.

What changed

A Probe SonarQube Cloud step runs before the begin pass and asks sonarcloud.io whether it is there. Three attempts with backoff, because the point is to tell an outage from a blip — analysis is worth having, and one slow response should not cost a run its quality gate. Begin SonarQube and End SonarQube are both gated on the answer.

The end pass gets the same judgement for an outage that starts after the probe. If the upload fails, the server is re-checked: forgiven only when it is genuinely unreachable, so a malformed report, a bad token or a rejected analysis still fails the step.

Where the gate is blocking, an outage still fails

SONAR_BLOCKING_GATE opts a repository into sonar.qualitygate.wait=true. None of the tolerance above applies there:

• The probe exits 1 rather than skipping. The Release step names no status function in its if:, so it is implicitly gated on the steps before it succeeding — and a skipped step is not a failed one. Forgiving an outage would release past the very gate the repository opted into.
• The end pass is never forgiven either, because with qualitygate.wait=true a failed gate is one of the ways that command exits non-zero, and an unreachable server is not evidence about which one happened.

Skipping is loud, and never dressed up as a pass

No quality gate is produced when analysis is skipped, so the SonarCloud check simply does not report — it is never made to look as though it passed. A warning annotation and a job summary say why, and a branch rule that requires the check still holds the merge until a human decides otherwise.

How this was checked

Both step scripts were parsed with the PowerShell parser and then exercised under pwsh 7.4 outside CI, capturing the process exit code rather than a pipeline's:

case	expected	observed
probe, server reachable	available=true, exit 0, no summary	✅
probe, unreachable, advisory gate	available=false, warning, summary, exit 0	✅
probe, unreachable, blocking gate	available=false, ::error, exit 1	✅
end, scanner succeeds	exit 0, silent	✅
end, scanner fails, blocking gate	exit 1, no annotation	✅
end, scanner fails, server answering	::error, exit 1	✅
end, scanner fails, server unreachable	::warning, summary, exit 0	✅

One thing worth confirming, because it is the load-bearing assumption of the forgiving branch: a leftover non-zero $LASTEXITCODE from the scanner does not leak into the exit code of pwsh -Command ". 'script'", which is how a shell: pwsh step is invoked. Tested directly with a native command exiting 1 — the step exits 0.

Note on where this file comes from

.github/workflows/dotnet.yml is the centrally-synced workflow, so this change will be overwritten the next time it syncs unless the same edit is carried to the central source. The equivalent change for ImageGui's own dotnet-private.yaml is in ktsu-dev/ImageGui#29.

🤖 Generated with Claude Code

https://claude.ai/code/session_015qxqZVzN8CJcDxTb5gtWua

---

Generated by Claude Code