Expand automated test coverage in CI #5

Closed
opened 2026-07-07 16:51:28 +00:00 by claude-bot · 2 comments
Contributor

Goal

Make CI exercise everything it should. Today's pipeline lints and builds the frontend and runs backend pytest, but several existing test suites and safety checks are never run in CI.

Gaps to close

  • Frontend unit tests — run Vitest / React Testing Library (M6 component tests exist but CI only lints + builds).
  • E2E — run the Playwright happy-path suite (browse → edit → approve → push) in CI.
  • Container health smoke test — after the image builds, boot it and assert GET /api/v1/health returns 200 (matches the M0 exit criterion).
  • Dependency audits — run pip-audit (backend) and npm audit (frontend) as a CI job.
  • Alembic migration check — assert there are no un-generated model changes / migrations apply cleanly on a fresh DB.
  • Optionally: coverage reporting with a soft threshold; Dockerfile lint (hadolint); image vulnerability scan (trivy/grype).

Acceptance criteria

  • Vitest and Playwright suites run and pass in CI
  • A booted-container health check gates the build job
  • pip-audit + npm audit run (non-blocking or blocking, decided in review)
  • Migration consistency is verified in CI

Depends on: CI migration to Forgejo Actions.

## Goal Make CI exercise everything it should. Today's pipeline lints and builds the frontend and runs backend pytest, but several existing test suites and safety checks are never run in CI. ## Gaps to close - [ ] **Frontend unit tests** — run Vitest / React Testing Library (M6 component tests exist but CI only lints + builds). - [ ] **E2E** — run the Playwright happy-path suite (browse → edit → approve → push) in CI. - [ ] **Container health smoke test** — after the image builds, boot it and assert `GET /api/v1/health` returns 200 (matches the M0 exit criterion). - [ ] **Dependency audits** — run `pip-audit` (backend) and `npm audit` (frontend) as a CI job. - [ ] **Alembic migration check** — assert there are no un-generated model changes / migrations apply cleanly on a fresh DB. - [ ] Optionally: coverage reporting with a soft threshold; Dockerfile lint (hadolint); image vulnerability scan (trivy/grype). ## Acceptance criteria - [ ] Vitest and Playwright suites run and pass in CI - [ ] A booted-container health check gates the build job - [ ] `pip-audit` + `npm audit` run (non-blocking or blocking, decided in review) - [ ] Migration consistency is verified in CI Depends on: CI migration to Forgejo Actions.
claude-bot added this to the v1.0.0 milestone 2026-07-15 15:33:03 +00:00
Author
Contributor

Context from #41 (merged): the docker-e2e job now runs the Playwright happy-path suite in CI and passes — the E2E-in-CI item on this issue's list is effectively delivered. Getting there required rewiring the job for the Forgejo runner (container-name networking instead of host ports; docker cp instead of bind mounts; idempotent cleanup of the reused docker host).

Two non-blocking hardening/optimization follow-ups discovered while doing it, good to fold into this issue's scope:

  • --ipc=host on the Playwright container — Chromium ran fine on the default 64MB /dev/shm this time, but that's the #1 flakiness source for Playwright-in-Docker. Adding --ipc=host (per Playwright's Docker docs) is cheap insurance against intermittent hangs. (I have the one-line diff ready.)
  • docker-e2e wall-clock is ~35 min, almost entirely the emulated linux/arm64 multi-arch build under QEMU. Consider building only linux/amd64 on PRs and reserving the arm64/multi-arch validation for pushes to main / tags (pairs with #3/#64). Would cut PR feedback time dramatically.
  • Concurrency note: the E2E job uses fixed iris/pw/iris-net names with pre-run cleanup — fine for serialized PR CI, but if runs ever overlap on the shared runner host they'd collide. Run-scoped names would make it robust.

Also: the other items still open here (Vitest already runs, pip-audit/npm-audit now gating-clean, migration check) — worth reconciling this checklist against what #41 already turned on.

Context from #41 (merged): the docker-e2e job now **runs the Playwright happy-path suite in CI and passes** — the E2E-in-CI item on this issue's list is effectively delivered. Getting there required rewiring the job for the Forgejo runner (container-name networking instead of host ports; `docker cp` instead of bind mounts; idempotent cleanup of the reused docker host). Two non-blocking hardening/optimization follow-ups discovered while doing it, good to fold into this issue's scope: - [ ] **`--ipc=host` on the Playwright container** — Chromium ran fine on the default 64MB `/dev/shm` this time, but that's the #1 flakiness source for Playwright-in-Docker. Adding `--ipc=host` (per Playwright's Docker docs) is cheap insurance against intermittent hangs. (I have the one-line diff ready.) - [ ] **docker-e2e wall-clock is ~35 min**, almost entirely the emulated `linux/arm64` multi-arch build under QEMU. Consider building only `linux/amd64` on PRs and reserving the arm64/multi-arch validation for pushes to `main` / tags (pairs with #3/#64). Would cut PR feedback time dramatically. - [ ] Concurrency note: the E2E job uses fixed `iris`/`pw`/`iris-net` names with pre-run cleanup — fine for serialized PR CI, but if runs ever overlap on the shared runner host they'd collide. Run-scoped names would make it robust. Also: the other items still open here (Vitest already runs, pip-audit/npm-audit now gating-clean, migration check) — worth reconciling this checklist against what #41 already turned on.
Author
Contributor

Audited against .forgejo/workflows/ on 2026-09-01 — all four acceptance criteria are met.

Gap Where it runs now
Frontend unit tests (Vitest) ci.ymlFrontend lint, test & buildUnit tests (Vitest)
E2E (Playwright) ci.ymlDocker build, health smoke & E2ERun E2E (Playwright), from a sibling container on the job network, image tag derived from package-lock.json (#38/#39)
Container health smoke Same job → Wait for health, polling /api/v1/health against the booted image and dumping docker logs on failure
Dependency audits audit.ymlpip-audit + npm audit --audit-level=high, weekly + workflow_dispatch
Alembic migration check ci.yml → dedicated Alembic migration check job: alembic upgrade head on a fresh DB, then alembic check for un-generated model changes

The one deviation from the original text is deliberate: this issue said audits should run "as a CI job", and they now run in a separate scheduled workflow instead. That was decided in #81 — on this Forgejo runner continue-on-error: true does not stop a failing job from marking the whole run failure, so an advisory audit inside ci.yml reddened every PR and would have blocked #56 outright. This issue's acceptance criterion allowed for it: "non-blocking or blocking, decided in review." It was reviewed and decided.

The remaining unchecked line is the explicitly optional one — coverage thresholds, hadolint, trivy. None of those are acceptance criteria, and I'd rather they be their own issue if wanted than keep this one open.

Closing as done.

**Audited against `.forgejo/workflows/` on 2026-09-01 — all four acceptance criteria are met.** | Gap | Where it runs now | |---|---| | Frontend unit tests (Vitest) | `ci.yml` → *Frontend lint, test & build* → **Unit tests (Vitest)** | | E2E (Playwright) | `ci.yml` → *Docker build, health smoke & E2E* → **Run E2E (Playwright)**, from a sibling container on the job network, image tag derived from `package-lock.json` (#38/#39) | | Container health smoke | Same job → **Wait for health**, polling `/api/v1/health` against the booted image and dumping `docker logs` on failure | | Dependency audits | `audit.yml` — `pip-audit` + `npm audit --audit-level=high`, weekly + `workflow_dispatch` | | Alembic migration check | `ci.yml` → dedicated *Alembic migration check* job: `alembic upgrade head` on a fresh DB, then `alembic check` for un-generated model changes | The one deviation from the original text is deliberate: this issue said audits should run "as a CI job", and they now run in a **separate scheduled workflow** instead. That was decided in #81 — on this Forgejo runner `continue-on-error: true` does not stop a failing job from marking the whole run `failure`, so an advisory audit inside `ci.yml` reddened every PR and would have blocked #56 outright. This issue's acceptance criterion allowed for it: *"non-blocking or blocking, decided in review."* It was reviewed and decided. The remaining unchecked line is the explicitly **optional** one — coverage thresholds, hadolint, trivy. None of those are acceptance criteria, and I'd rather they be their own issue if wanted than keep this one open. Closing as done.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
rbrooks/Iris-WLED#5
No description provided.