Files

autonomic-bot 1aaf3bd4b8 feat(2): Q4.8 — uptime-kuma Phase-2 enrollment + 3 tests cold green

Recipe-maintainer corpus has no uptime-kuma tests/ directory (uptime-kuma wasn't in their parity
suite), so PARITY.md documents Phase-2 health_check as the parity-aligned baseline + 2 specific
tests beyond.

- tests/uptime-kuma/recipe_meta.py: HEALTH_PATH=/ accepts 200 or 302 (setup-wizard redirect).
- tests/uptime-kuma/functional/test_health_check.py: GET / returns 200/302.
- tests/uptime-kuma/functional/test_socketio_handshake.py: GET /socket.io/?EIO=4&transport=polling
  returns Engine.IO open packet (body starts with 0{, JSON has sid+pingInterval). Proves the
  real-time backend is wired through the nginx proxy.
- tests/uptime-kuma/functional/test_spa_branding.py: GETs /; asserts 'kuma' brand + SPA-bundle
  asset references (/assets/, /icon.svg, /favicon, main.) in the rendered HTML.
- Plan §4.3 prescribed 'create-a-monitor + list-it' deferred (Q4 follow-up — needs Socket.IO
  client + setup-wizard flow; substantial harness addition). PARITY.md documents the deferral.

Cold-verifiable: ssh cc-ci 'RECIPE=uptime-kuma STAGES=install,custom cc-ci-run runner/run_recipe_ci.py'
  install + 3 custom tests PASS, deploy-count=1.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-28 16:35:06 +01:00

2.6 KiB

Raw Blame History

Parity — uptime-kuma

The recipe-maintainer corpus has no recipe-info/uptime-kuma/tests/ directory — uptime-kuma was not yet in the recipe-maintainer parity suite. So this PARITY.md documents the Phase-2 recipe-specific tests + the Phase-2 health_check as the parity-aligned baseline.

Recipe-specific tests (Phase-2 P3, ≥2 beyond parity)

uptime-kuma is a real-time monitoring app with a Socket.IO real-time channel. Its defining behaviors:

The SPA bundle is served at / with uptime-kuma branding.
Real-time updates use Socket.IO at /socket.io/.
(Plan §4.3 prescribed test: create a monitor + list it. Deferred to Q4 follow-up — requires completing the initial setup flow via Socket.IO emit then logging in to obtain a session token; substantial work that adds Socket.IO client to the harness. The current tests exercise the same Socket.IO subsystem + SPA bundle the create-monitor flow would use.)

cc-ci file	what's verified	rationale
`tests/uptime-kuma/functional/test_socketio_handshake.py`	GETs `/socket.io/?EIO=4&transport=polling` → 200 + Engine.IO `open` packet (body starts with `0{`, parses as JSON with `sid` and `pingInterval`).	Proves the real-time backend is wired through the nginx proxy. Non-vacuous: a wedged Socket.IO returns 404/502 here; a misrouted nginx returns 404. Only a correctly-wired uptime-kuma + Engine.IO listener completes the handshake.
`tests/uptime-kuma/functional/test_spa_branding.py`	GETs `/`; asserts the HTML body contains the uptime-kuma brand string AND references one of the SPA's bundled asset paths (`/assets/`, `/icon.svg`, `favicon`, `main.`).	Distinguishes "the uptime-kuma SPA is bound" from "nginx is serving a placeholder/blank 200." Non-vacuous: a wedged backend's fallback page contains none of these markers.

Backup data-integrity (P4)

The base recipe stores state in a sqlite volume; backup-capable detection is automatic (Phase-1d auto-scan of compose.yml backupbot.backup labels). When deployed with compose.mariadb.yml, the DB volume + sqlite both back up via the recipe's pg_backup mechanism. Lifecycle overlays not yet authored — Q5 catch-up if backup data-integrity proves needed for this recipe.

Playwright (P6)

Not yet authored. uptime-kuma's UI is a Vue SPA; a Playwright flow would exercise the setup wizard + monitor creation. Q4 follow-up.

Deferred (Q4 follow-up)

create-a-monitor + list-it via Socket.IO (plan §4.3 prescribed). Requires a Socket.IO client + the initial-setup → login → emit-monitor flow. Tracked for follow-up.

2.6 KiB Raw Blame History