chore: make SonarQube + Tailscale non-blocking in Kotlin CI [CPONETOPS-1078] - #320
Merged
Merged
Conversation
…S-1078] SonarQube is self-hosted behind the Monta VPN, so the Kotlin CI reuses a Tailscale bring-up step before the scan. Infra outages on that path — an expired/rotated headscale auth key, the Tailscale package CDN returning 504 (AWS CloudFront), or SonarQube being unreachable — currently fail the whole job and block every Kotlin PR and deploy, even though SonarQube is advisory. - pull-request-kotlin.yml: add continue-on-error to the Tailscale step and default sonar-non-blocking to true. Tests and lint still gate; only the VPN bring-up and Sonar upload are best-effort. - sonar-cloud.yml: add a sonar-non-blocking input (default true), make the Tailscale step non-blocking, and split "Build and analyze" so tests + kover still gate while the SonarQube scan is best-effort. - docs/workflow-guide.md: document the new input, default, and TAILSCALE_AUTHKEY. Callers wanting SonarQube to remain a hard gate can pass sonar-non-blocking: false. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0134BvmGHE9QM5zwSAzfJJUv
mtib
requested review from
JesperTerkelsen and
tobias0106
and removed request for
a team
July 16, 2026 09:41
JesperTerkelsen
approved these changes
Jul 16, 2026
mtib
added a commit
that referenced
this pull request
Jul 16, 2026
…078] (#321) * chore: skip SonarQube scan when Tailscale bring-up fails [CPONETOPS-1078] Follow-up to #320. Making the Tailscale step continue-on-error stops it from failing the job, but the SonarQube step then still ran against a dead VPN, failing ~30s later and logging a confusing error (job passed, but noisily). Gate the Sonar step on the Tailscale step's outcome so a failed VPN bring-up skips the scan entirely instead of running it doomed. Using `outcome != 'failure'` (rather than `== 'success'`) keeps the SonarCloud path working when Tailscale is skipped because no TAILSCALE_AUTHKEY is passed. Applied to both pull-request-kotlin.yml and sonar-cloud.yml. With sonar-non-blocking: false the Tailscale failure still hard-fails the job (the scan is a required gate, so an unreachable SonarQube should block). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0134BvmGHE9QM5zwSAzfJJUv * chore: trim comments on Sonar skip condition Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0134BvmGHE9QM5zwSAzfJJUv --------- Co-authored-by: Claude Opus 4.8 (1M context) <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
2 participants
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.
What
Make the Tailscale VPN bring-up and the SonarQube scan non-blocking by default in the Kotlin CI workflows, so infra outages on that path stop failing PRs and deploys.
SonarQube is self-hosted behind the Monta VPN, so
pull-request-kotlin.ymlandsonar-cloud.ymljoin Tailscale before scanning. Over the last day this path has repeatedly hard-failed the whole job and blocked deploys:TAILSCALE_AUTHKEYexpired/rotated early504(the AWS CloudFront incident), so the action couldn't even download thetailscalebinaryIn all these cases SonarQube is advisory, yet the failure gated every Kotlin PR and deploy.
Changes
pull-request-kotlin.ymlcontinue-on-erroron theTailscalestep (previously it had none → any VPN/binary-download failure failed the job)sonar-non-blockingnow defaults totrue(theUpload results to SonarQubestep already honoured it)sonar-cloud.ymlsonar-non-blockinginput (defaulttrue)continue-on-erroron theTailscalesteptest koverXmlReport sonarinto a gating Run tests with coverage step and a best-effort Analyze with SonarQube step, so tests still fail the job but the scan does not (mirrors the structure already used inpull-request-kotlin.yml)docs/workflow-guide.md— documentsonar-non-blocking, the new default, and the optionalTAILSCALE_AUTHKEYsecretBehavioural change / tradeoff
SonarQube becomes advisory by default for all repos consuming these
@mainworkflows. This is the intended fix to unblock deploys during the current outage. The known downside (raised in#guild-kotlin-backend): a genuine Sonar quality-gate failure won't block and may go unnoticed. Repos that want SonarQube to remain a hard gate can opt back in with:Longer term the plan discussed is to move Sonar off the VPN path (self-hosted runners fetching directly), which would remove the Tailscale dependency entirely.
Validation
actionlintpasses clean on both changed workflowsCPONETOPS-1078