[Fleet Monitor] petry-projects/google-app-scripts — .github/workflows/coverage.yml

[don-petry]

🟡 WARNING: petry-projects/google-app-scripts / .github/workflows/coverage.yml

Metric	Value
Failure Rate	13.3% (2 / 15 runs)
Status	WARNING
p50 Duration	29s
p95 Duration	71s
Successful Runs	13
Cancelled Runs	0

Workflow: .github/workflows/coverage.yml

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

[don-petry]

Dev-Lead Implementation Plan

Issue: #532 — [Fleet Monitor] petry-projects/google-app-scripts — .github/workflows/coverage.yml

Root-Cause Analysis

Reviewed the 2 failing runs in the monitored window:

• Run 31549895631 (feat/tag-based-retention-policy): jest coverageThreshold correctly failed a branch that added gitHubSync.gs at ~35% coverage.
• Run 31528732672 (dev-lead/issue-521): 18 unit tests failed + coverage below threshold on an in-progress branch.

Both failures were the coverage gate working as intended — legitimate rejections of under-covered / failing PR branches, not infrastructure flakiness. Weakening the gate would be incorrect, so no threshold is being lowered.

However, the investigation surfaced a genuine latent defect in the workflow's own enforcement step (scripts/check-coverage.js, run by the "Enforce coverage" step):

• Its lines metric is a dead no-op: jest's coverage-final.json contains no l (line) map, so totals.lines stays {covered:0,total:0} and the script unconditionally prints lines: 100% (0/0) — it never validates line coverage.
• Its lines threshold (100) also contradicts the documented 99% standard in AGENTS.md and jest.config.js.
• The script has no unit tests.

Scope

Make scripts/check-coverage.js actually validate line coverage (derived from statementMap), align its lines threshold to the documented 99%, and add the missing unit tests — without weakening any real gate.

Implementation Checklist

• Refactor scripts/check-coverage.js to export computeTotals() / evaluate() and guard CLI execution with require.main === module
• Derive line coverage per-file from statementMap + s (a line counts as covered if any statement starting on it executed)
• Set requiredCoverage.lines to 99 (matching AGENTS.md and jest.config.js)

Tests to Write

• scripts/tests/check-coverage.test.js: computeTotals derives correct line totals from statementMap
• statements/branches/functions totals still computed correctly
• evaluate passes when all metrics meet thresholds and fails when the lines metric is below 99

Test Command

npm test (jest) — with node scripts/check-coverage.js for the gate check

[don-petry]

Dev-Lead: Implementation Complete

Root-Cause Summary

The two failures in the monitored window were legitimate coverage-gate rejections, not infrastructure flakiness:

• Run 31549895631 — jest coverageThreshold correctly failed feat/tag-based-retention-policy (added gitHubSync.gs at ~35%).
• Run 31528732672 — 18 unit tests failed + coverage below threshold on dev-lead/issue-521.

Both were the gate working as intended, so no threshold was lowered. Investigation did surface a genuine latent defect in the workflow's own enforcement step (scripts/check-coverage.js), which is what this change fixes.

The Defect Fixed

scripts/check-coverage.js (the "Enforce coverage" step) had a dead lines metric: jest's coverage-final.json has no l (line) map, so it always reported lines: 100% (0/0) and never actually validated line coverage. Its lines threshold (100) also contradicted the documented 99% standard in AGENTS.md/jest.config.js. The script had no unit tests.

Fix:

• Derive line coverage per-file from statementMap + s (a line is covered if any statement starting on it executed). Verified against jest: derived 99.17% vs jest's 99.16%.
• Align lines threshold to 99 (matches AGENTS.md and jest.config.js).
• Refactor into exported computeTotals() / evaluate() with a require.main === module CLI guard so it is unit-testable per repo conventions.
• Add scripts/tests/check-coverage.test.js (8 tests). Main stays green (99.17% ≥ 99); statements/branches/functions logic unchanged.

Plan Execution

• Posted root-cause + plan to issue
• Wrote failing tests first (red)
• Fixed check-coverage.js (green)
• Full suite, gate script, dev-lead lint, npm run check, prettier all pass
• Rubber-duck review of diff

Test Results

Enforce-coverage gate (node scripts/check-coverage.js):
✅ statements     : 98.71% (1146/1161) [required: 95%]
✅ branches       : 90.19% (625/693) [required: 85%]
✅ functions      : 97.50% (117/120) [required: 95%]
✅ lines          : 99.17% (1075/1084) [required: 99%]
✅ All coverage metrics meet requirements.

Test Suites: 16 passed, 16 total
Tests:       411 passed, 411 total
Snapshots:   0 total

dev-lead-lint.sh: all checks passed
npm run check: exit 0 (22 pre-existing warnings in unrelated gmail-to-drive-by-labels tests; none from this change)

Files Changed

• scripts/check-coverage.js: real line-coverage derivation from statementMap; lines threshold 100 → 99; exported functions + CLI guard.
• scripts/tests/check-coverage.test.js: new unit tests (8) for computeTotals/evaluate and thresholds.

Notes

The Fleet Monitor failure-rate metric counted legitimate PR-branch gate rejections; those are expected behavior for a coverage gate and were intentionally not "fixed" by weakening thresholds. This change makes the secondary enforcement script honest and consistent with the documented standard. No behavior change for compliant code on main.

[don-petry]

✅ Auto-resolved by Fleet Monitor. This workflow's failure rate has been below the 10% threshold (or the workflow was removed) since 2026-08-12 (3 days) — the monitor stopped flagging it. Closing. It will reopen automatically if the workflow crosses the threshold again.