You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Look into why sonarcloud.yml is over the failure-rate threshold. Finding: the workflow has no defect, so no code change is planned.
Root-cause analysis
I pulled logs for the failed runs in the monitored window. Both were pull_request runs on feature branches that had real problems at that commit. Neither failure came from the workflow, the runner, or SonarCloud itself.
Every run of this workflow on main succeeded. The 14.3% rate (1/7) is the job doing what it should: rejecting broken PR commits that were fixed before merge.
I also ran the workflow's steps locally against current main (npm ci --ignore-scripts, then npm test -- --coverage --coverageThreshold='{}'). Both succeed: 23/23 suites, 1130/1130 tests.
Implementation Checklist
Check the workflow config (SHA-pinned actions, token-gated scan step, coverage step that ignores thresholds). No change needed.
Check the failed-run logs. Both failures came from the PR code, not the workflow.
Tests to Write
None. This is a config/diagnostic issue with no behavior change, so the TDD phase does not apply.
Test Command
npm test
Recommendation
Close as not a workflow defect. If the Fleet Monitor should stop flagging this kind of failure, it could count only push/main runs, or leave out PR runs whose failure also shows up in CI on the same SHA. That change would go in the monitor, not in this repo.
β Auto-resolved by Fleet Monitor. This workflow's failure rate has been below the 10% threshold (or the workflow was removed) since 2026-11-05 (3 days) β the monitor stopped flagging it. Closing. It will reopen automatically if the workflow crosses the threshold again.
Activity
don-petry commentedon Nov 5, 2026
Dev-Lead Implementation Plan
Issue: #669 β [Fleet Monitor] combsmith/google-app-scripts β .github/workflows/sonarcloud.yml
Scope
Look into why
sonarcloud.ymlis over the failure-rate threshold. Finding: the workflow has no defect, so no code change is planned.Root-cause analysis
I pulled logs for the failed runs in the monitored window. Both were
pull_requestruns on feature branches that had real problems at that commit. Neither failure came from the workflow, the runner, or SonarCloud itself.fix/npm-audit-glob-minimatchnpm ciEUSAGE:package.jsonoverrides were out of sync withpackage-lock.json(Missing: glob@10.5.0 from lock file).CIfailed on the same commit too.dev-lead/issue-665-β¦npm testTypeError: The "original" argument must be of type functionfrom in-progress code on that PREvery run of this workflow on
mainsucceeded. The 14.3% rate (1/7) is the job doing what it should: rejecting broken PR commits that were fixed before merge.I also ran the workflow's steps locally against current
main(npm ci --ignore-scripts, thennpm test -- --coverage --coverageThreshold='{}'). Both succeed: 23/23 suites, 1130/1130 tests.Implementation Checklist
Tests to Write
None. This is a config/diagnostic issue with no behavior change, so the TDD phase does not apply.
Test Command
npm testRecommendation
Close as not a workflow defect. If the Fleet Monitor should stop flagging this kind of failure, it could count only
push/mainruns, or leave out PR runs whose failure also shows up inCIon the same SHA. That change would go in the monitor, not in this repo.don-petry commentedon Nov 8, 2026
β Auto-resolved by Fleet Monitor. This workflow's failure rate has been below the 10% threshold (or the workflow was removed) since 2026-11-05 (3 days) β the monitor stopped flagging it. Closing. It will reopen automatically if the workflow crosses the threshold again.