[Fleet Monitor] petry-projects/.github-private — sonarcloud.yml #430

Activity

1. don-petry

   added

   health-checkAutomated health check reportAutomated health check report

   dev-leadFor dev-lead agent pickupFor dev-lead agent pickup

   fleet-trackerTracked by the Actions Fleet MonitorTracked by the Actions Fleet Monitor

   and removed

   dev-leadFor dev-lead agent pickupFor dev-lead agent pickup

   on Jun 4, 2026
2. don-petry commented on Jun 8, 2026

   

   don-petry

   on Jun 8, 2026

   CollaboratorAuthor

   More actions

   Dev-Lead Implementation Plan

   Issue: #430 — [Fleet Monitor] petry-projects/.github-private — sonarcloud.yml

   Root Cause Analysis

   All 8 failures occurred on 2026-06-03/04 with the same error:

   org.sonarsource.scanner.lib.internal.http.HttpException:
   GET https://scanner.sonarcloud.io/jres/OpenJDK21U-jre_x64_linux_hotspot_21.0.9_10.tar.gz
   failed with HTTP 403 Forbidden
   

   The SonarScanner CLI downloads a managed JRE from SonarCloud's own servers on every run. During the failure window, SonarCloud's JRE distribution endpoint was returning HTTP 403, causing all scans to fail regardless of branch or code content. Runs since 2026-06-05 are fully passing (same action version).

   Scope

   Pre-install Java 21 in the workflow and configure the scanner to use it, so the job no longer depends on SonarCloud's JRE download endpoint. This eliminates the class of failure seen in the monitored window.

   Implementation Checklist

   • Add actions/setup-java@v5.2.0 step (SHA-pinned) before the SonarCloud scan
   • Pass -Dsonar.scanner.javaExePath pointing to the pre-installed JRE via the scanner args input
   • Verify the workflow is still syntactically valid YAML

   Tests to Write

   Exception: This is a pure workflow configuration change with no observable behavioral difference in normal operation (the scan logic is unchanged; only the JRE source changes). No failing unit tests are appropriate. Verification is done by confirming YAML is valid and the lint script passes.

   Test Command

   bash scripts/dev-lead-lint.sh
3. don-petry commented on Jun 8, 2026

   

   don-petry

   on Jun 8, 2026

   CollaboratorAuthor

   More actions

   Dev-Lead: Implementation Complete

   Root Cause

   All 8 failures occurred on 2026-06-03/04 with identical errors:

   org.sonarsource.scanner.lib.internal.http.HttpException:
   GET https://scanner.sonarcloud.io/jres/OpenJDK21U-jre_x64_linux_hotspot_21.0.9_10.tar.gz
   failed with HTTP 403 Forbidden
   

   The SonarScanner CLI (v8.1.0) downloads a managed JRE from SonarCloud's own distribution endpoint on every run. SonarCloud's JRE endpoint was returning HTTP 403 during that window, causing all scans to fail regardless of branch. Runs since 2026-06-05 pass with the unchanged workflow, confirming this was a SonarCloud server-side outage, not a configuration regression.

   Plan Execution

   • Diagnosed root cause from failed run logs (HTTP 403 on scanner.sonarcloud.io/jres/...)
   • Added actions/setup-java@v5.2.0 (SHA-pinned) to pre-install JDK 21 before the scan
   • Passed -Dsonar.scanner.javaExePath pointing to the pre-installed JRE so the scanner skips its own JRE provisioning step
   • Validated YAML syntax is valid
   • bash scripts/dev-lead-lint.sh — all checks passed

   Test Results

     [lint] shellcheck on 34 file(s)...
     [lint] validating 4 agent profile(s)...
   OK: agents/agentic-workflows.md
   OK: agents/compliance-auditor.md
   OK: agents/feature-ideator.md
   OK: agents/pr-reviewer.md
     [lint] all checks passed
   

   Phase 2 exception: This is a pure workflow configuration change. The scan logic is unchanged; only the JRE source changes from SonarCloud's download endpoint to a pre-installed Temurin JDK. No unit tests are applicable; correctness is verified by CI run results.

   Files Changed

   • .github/workflows/sonarcloud.yml: Added actions/setup-java@v5.2.0 step and configured scanner to use pre-installed JRE via sonar.scanner.javaExePath, removing the dependency on SonarCloud's JRE distribution endpoint

   Notes

   • actions/setup-java output path is documented as "same as $JAVA_HOME", so ${{ steps.setup-java.outputs.path }}/bin/java is the correct path to the Java executable
   • If SONAR_TOKEN is absent the scan step is still skipped (unchanged behaviour); the setup-java step runs but is harmless
   • If SonarCloud has another JRE endpoint outage, the scan will now succeed using the pre-installed JRE instead of failing
4. don-petry

   added a commit that references this issue on Jun 8, 2026

   feat: implement issue #430 — [Fleet Monitor] petry-projects/.github-p…

   ...

   6177b5c
5. don-petry

   closed this as completedin #475on Jun 8, 2026
6. don-petry

   added 2 commits that reference this issue on Jun 12, 2026

   feat: implement issue #430 — [Fleet Monitor] petry-projects/.github-p…

   ...

   1d4b652

   feat: implement issue #430 — [Fleet Monitor] petry-projects/.github-p…

   ...

   5486a5c