[Fleet Monitor] petry-projects/google-app-scripts — sonarcloud.yml

[don-petry]

🟠 DEGRADED: petry-projects/google-app-scripts / sonarcloud.yml

Metric	Value
Failure Rate	22.2% (2 / 9 runs)
Status	DEGRADED
p50 Duration	137s
p95 Duration	1137s
Successful Runs	7
Cancelled Runs	0

Workflow: sonarcloud.yml

Last updated by Fleet Monitor run on 2026-06-04.
Threshold: failure rate > 10% over the monitored window.

[don-petry]

Dev-Lead Implementation Plan

Issue: #367 — [Fleet Monitor] petry-projects/google-app-scripts — sonarcloud.yml

Root Cause

Both failures (runs 26925310740 and 26885030575) show the exact same error:

Downloading from: https://binaries.sonarsource.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-8.1.0.6389-linux-x64.zip
##[error]Action failed: Unexpected HTTP response: 403

The SonarSource/sonarqube-scan-action downloads the sonar-scanner binary on every run. SonarSource's CDN returns an intermittent 403 Forbidden, causing ~22% of runs to fail.

Scope

Add caching for the sonar-scanner binary and a retry step so that transient 403 errors from SonarSource's CDN don't cause workflow failures.

Implementation Checklist

• .github/workflows/sonarcloud.yml: Add actions: write permission (required for actions/cache)
• .github/workflows/sonarcloud.yml: Add Cache sonar-scanner step using actions/cache@v5 pointing at ${{ runner.tool_cache }}/sonar-scanner
• .github/workflows/sonarcloud.yml: Add id: sonar_scan and continue-on-error: true to the existing scan step
• .github/workflows/sonarcloud.yml: Add SonarCloud Scan (retry) step that runs only when the first scan fails

Tests to Write

Exception: This is a pure CI configuration change with no observable behavioral change in application code. No unit tests apply. The fix is verified by the workflow running successfully.

Test Command

npm test (repo tests — no change to application logic)

[don-petry]

Dev-Lead: Implementation Complete

Root Cause

Both failures were identical: ##[error]Action failed: Unexpected HTTP response: 403 when downloading the sonar-scanner binary from https://binaries.sonarsource.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-8.1.0.6389-linux-x64.zip. The sonarqube-scan-action downloads this binary on every run with no retry or caching, making the workflow vulnerable to transient CDN 403 errors.

Plan Execution

• .github/workflows/sonarcloud.yml: Added actions: write permission (required for actions/cache to save entries)
• .github/workflows/sonarcloud.yml: Added Cache sonar-scanner step using actions/cache@v5 (27d5ce7f107fe9357f9df03efb73ab90386fccae) pointing at ${{ runner.tool_cache }}/sonar-scanner
• .github/workflows/sonarcloud.yml: Added id: sonar_scan and continue-on-error: true to the existing scan step
• .github/workflows/sonarcloud.yml: Added SonarCloud Scan (retry) step that runs only when steps.sonar_scan.outcome == 'failure'

How the fix works

1. Caching: The sonar-scanner binary is cached in ${{ runner.tool_cache }}/sonar-scanner across runs. On cache hit, the action finds the tool already extracted and skips the download entirely — eliminating the 403 risk.
2. Retry: On cache miss (first run or expired cache), if the download fails with 403, the retry step attempts the scan again immediately. Since the 403 is transient (CDN blip), a second attempt typically succeeds.

Test Results

> google-app-scripts@0.0.0 test
> jest --runInBand

Test Suites: 12 passed, 12 total
Tests:       301 passed, 301 total
Snapshots:   0 total
Time:        4.155 s
Ran all test suites.

Format check: ✅ All files use Prettier code style
Lint: ✅ 0 errors (22 pre-existing warnings unrelated to this change)

Files Changed

• .github/workflows/sonarcloud.yml: Added scanner binary caching and a retry step to handle transient HTTP 403 errors from SonarSource's CDN

Notes

• This is a CI configuration-only change; no application logic was modified, so TDD does not apply.
• The cache key sonar-scanner-${{ runner.os }}-8.1.0.6389 is version-pinned. If the action is upgraded to a different scanner version, the cache will correctly miss and be repopulated.
• Duplicate SonarCloud analysis on retry is handled gracefully by SonarCloud (last result wins).