Wire coverage reporting and minimum threshold in CI #50

New issue

Closed

opened 2026-08-04 03:54:07 +00:00 by Mark · 0 comments

Mark commented

2026-08-04 03:54:07 +00:00

Owner

Goal

Wire code coverage reporting into nodedesk's CI pipeline, generate a coverage artifact on every run, and enforce a minimum coverage threshold so a regression that drops coverage below the configured floor fails the build.

Background

@vitest/coverage-v8 is already installed (commit 2f8684e on ci/quality-gates-matrix / PR #45).
vitest.config.ts has no coverage block — no provider, no reporter, no thresholds.
package.json has no coverage script.
.forgejo/workflows/ci.yml (PR #45, head 2f8684e) has no coverage step — it runs lint, typecheck, unit, and build only.
Sibling coverage-related issue: Mark/nodedesk#47 (Define target CI pipeline stages and gate policy) — this issue is one concrete gate that #47 references in its list of gates.
Related sibling issues:
- #46 — Add integration test coverage for core auth/paywall/CRUD/export
- #48 — Design CI workflow skeleton
- #49 — Quarantine flaky e2e tests

Acceptance criteria

vitest.config.ts defines a coverage block with provider: 'v8', reporter: ['text', 'lcov', 'cobertura'], and include/exclude patterns that match the existing test config (excludes tests/**, node_modules/**, .kilo/**, .venv/**).
package.json adds test:unit:coverage (and coverage alias) running vitest run --coverage.
CI workflow (.forgejo/workflows/ci.yml) gains a coverage step in the unit job (Node 20 only — no need to run twice in the matrix): produces text + lcov + cobertura reports, uploads lcov artifact, and runs npx vitest run --coverage --coverage.thresholds.lines=... with a fail-under threshold reflecting the baseline.
Threshold rationale documented in this issue body: baseline is the post-#45 line coverage on the touched modules (attachments 100%, guard 93.75%, env 75.4%, csv 100% — overall repo coverage is unknown until the worker measures it). Recommended floor: round measured baseline down to the nearest 5%, then subtract 2pp slack to avoid spurious gate failures on the first run. Document the measured value and the chosen floor in the PR.
CI job fails when coverage drops below the configured threshold.
Coverage delta is posted as a CI summary or Forgejo comment (PR comment) showing overall % and per-file deltas vs main.

Out of scope

Per-line uncovered-line annotations as blocking gates (line-level reporting only).
Branch-coverage / function-coverage floors (lines-only is enough for v1; revisit in a follow-up if the data warrants it).
Coverage on the e2e Playwright suite (Playwright has separate coverage tooling not currently in the project).
Bumping the threshold upward over time — that is a separate follow-up issue once this gate is stable.

Notes

Run on the ci/quality-gates-matrix branch (PR #45) — do not open a new branch. This is a follow-up commit on the existing quality-gate PR.
Coordinate with the worker handling #47 (gate policy) so coverage appears in the documented gate list.
@vitest/coverage-v8 ^4.1.10 is already a devDependency.

## Goal Wire code coverage reporting into nodedesk's CI pipeline, generate a coverage artifact on every run, and enforce a minimum coverage threshold so a regression that drops coverage below the configured floor fails the build. ## Background - `@vitest/coverage-v8` is already installed (commit `2f8684e` on `ci/quality-gates-matrix` / PR #45). - `vitest.config.ts` has **no** `coverage` block — no `provider`, no `reporter`, no `thresholds`. - `package.json` has **no** `coverage` script. - `.forgejo/workflows/ci.yml` (PR #45, head `2f8684e`) has **no** coverage step — it runs lint, typecheck, unit, and build only. - Sibling coverage-related issue: **Mark/nodedesk#47** (Define target CI pipeline stages and gate policy) — this issue is one concrete gate that #47 references in its list of gates. - Related sibling issues: - #46 — Add integration test coverage for core auth/paywall/CRUD/export - #48 — Design CI workflow skeleton - #49 — Quarantine flaky e2e tests ## Acceptance criteria 1. `vitest.config.ts` defines a `coverage` block with `provider: 'v8'`, `reporter: ['text', 'lcov', 'cobertura']`, and `include`/`exclude` patterns that match the existing test config (excludes `tests/**`, `node_modules/**`, `.kilo/**`, `.venv/**`). 2. `package.json` adds `test:unit:coverage` (and `coverage` alias) running `vitest run --coverage`. 3. CI workflow (`.forgejo/workflows/ci.yml`) gains a coverage step in the `unit` job (Node 20 only — no need to run twice in the matrix): produces text + lcov + cobertura reports, uploads lcov artifact, and runs `npx vitest run --coverage --coverage.thresholds.lines=...` with a `fail-under` threshold reflecting the baseline. 4. Threshold rationale documented in this issue body: baseline is the post-#45 line coverage on the touched modules (attachments 100%, guard 93.75%, env 75.4%, csv 100% — overall repo coverage is unknown until the worker measures it). Recommended floor: round measured baseline **down** to the nearest 5%, then subtract 2pp slack to avoid spurious gate failures on the first run. Document the measured value and the chosen floor in the PR. 5. CI job **fails** when coverage drops below the configured threshold. 6. Coverage delta is posted as a CI summary or Forgejo comment (PR comment) showing overall % and per-file deltas vs `main`. ## Out of scope - Per-line uncovered-line annotations as blocking gates (line-level reporting only). - Branch-coverage / function-coverage floors (lines-only is enough for v1; revisit in a follow-up if the data warrants it). - Coverage on the e2e Playwright suite (Playwright has separate coverage tooling not currently in the project). - Bumping the threshold upward over time — that is a separate follow-up issue once this gate is stable. ## Notes - Run on the `ci/quality-gates-matrix` branch (PR #45) — do **not** open a new branch. This is a follow-up commit on the existing quality-gate PR. - Coordinate with the worker handling #47 (gate policy) so coverage appears in the documented gate list. - `@vitest/coverage-v8` ^4.1.10 is already a devDependency.