Release through a SonarQube Cloud outage

[matt-edmondson]

Requested by Matt · project thread

Before: if SonarCloud returned a server error during the analysis upload, the release run failed and nothing was released. This happened to ImGuiApp on 2026-09-30 (run): a CloudFront 502 came back from api.sonarcloud.io/analysis/analyses. The outage check after the failure only asked whether /api/server/version answered, and it did, so the failure counted as real. With SONAR_BLOCKING_GATE set, End SonarQube also exited before checking anything. By then the metadata commit for 3.58.0 was already on main, so a rerun could only fail with a non-fast-forward push.

After: a SonarCloud outage never holds a release, whether the quality gate is advisory or blocking. The run posts a warning and a step summary saying it released without a gate. A quality gate that SonarCloud evaluated and failed still blocks a release where SONAR_BLOCKING_GATE is set. Any other scanner failure, such as a bad token or a rejected analysis, still fails the run.

How:

• A new step writes sonar-helpers.ps1 to RUNNER_TEMP, and Begin and End both dot-source it.
• The helpers run the scanner, keep its output, and classify a failure from that output:
  • QUALITY GATE STATUS: FAILED is a gate failure.
  • Error 5xx on https://…, a 502/503/504 page, or a Java connection exception is an outage.
  • Otherwise, the /api/server/version probe decides: no answer means an outage, an answer means a real failure.
• Each step that sees an outage (the probe, Begin or End) sets an outage output and exits 0.
• If Begin fails from an outage, it also deletes .sonarqube, so the build does not pick up a half-written analysis config.
• End now runs only when Begin succeeded (began == 'true').
• Release goes ahead when any of the three outage outputs is set. A missing SONAR_TOKEN still holds a release under a blocking gate, as before.
• docs/shared-ci.md has a short section on this behaviour.

I tested the Begin and End scripts locally with pwsh 7.5 against a stub scanner. Covered cases:

• End: success, the real CloudFront 502 text on stderr, a failed gate (it still blocks even if a 503 also appears), a bad token, an unreachable server, and connection refused.
• Begin: success, an outage, and a bad token.

The stub runs under $ErrorActionPreference = 'stop', as GitHub's wrapper does.

Not changed:

• dotnet-private.yml has no blocking gate and does not release, so I left it alone.
• Consumers call @release, so this has no effect until the release tag is promoted.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CZA63NZqPgeDNmUhhMaXcH

---

Generated by Claude Code