28 lines
1.8 KiB
Markdown
28 lines
1.8 KiB
Markdown
# mattermost-lts — parity & coverage map (Phase 2)
|
|
|
|
## P2 — Parity port
|
|
**No recipe-maintainer corpus exists for mattermost-lts** (`/srv/recipe-maintainer/recipe-info/` has
|
|
no `mattermost-lts/` entry). P2 (parity) is therefore **vacuously satisfied** — there are no
|
|
`recipe-info/mattermost-lts/tests/*.py` scripts to port. Coverage is delivered entirely via the
|
|
generic lifecycle tiers (install/upgrade/backup/restore) + the recipe-specific functional tests below.
|
|
|
|
## Lifecycle (generic tiers — Phase 1d/1e)
|
|
mattermost-lts ships no `test_<op>.py` overlays, so the **generic** install/upgrade/backup/restore
|
|
tiers run by default (the Phase-1e invariant: no overlay ⇒ generic runs). The stack bundles its own
|
|
postgres in-compose (no external dep), so no dependency resolution is needed.
|
|
|
|
## P3 — Recipe-specific functional tests
|
|
- `functional/test_health_check.py`
|
|
- `test_root_serves` — web app served at `/` (200/302).
|
|
- `test_system_ping_ok` — GET `/api/v4/system/ping` → `{"status":"OK"}` (proves the mattermost
|
|
server + API router are live, not a Traefik fallback).
|
|
- `functional/test_create_message.py` — **§4.3 prescribed create-an-object + read-it-back** (planned,
|
|
authored against the live instance): create the first user (system admin) → login → create team →
|
|
create channel → POST a message → GET it back → assert the message text round-trips. *(In progress —
|
|
requires response-header access for the mattermost login `Token`; harness.http extension pending.)*
|
|
|
|
## P4 — Backup data-integrity
|
|
Planned `ops.py`: pre_backup seeds an identifiable message via the API; pre_restore mutates/wipes;
|
|
the restore assertion re-reads the message and asserts it survived (recipe-aware, not health-only).
|
|
*(Follows once the create-message API flow is proven green.)*
|