autonomic-bot
d9a446cd36
Some checks failed
continuous-integration/drone/push Build is failing
Enrolls wordpress as a maintained recipe (operator request 2026-08-03): - tests/wordpress/: recipe_meta (install-wizard-aware health 200/302, 900s deploy timeout for mariadb+core-copy first boot, WARM_CANONICAL), custom suite: health check, install-wizard completion + REST API round-trip (?rest_route= vs /wp-json/ splits DB vs .htaccess failure layers), and the sec4.3 post round-trip (XML-RPC write -> REST read -> permalink HTML, unique marker). PARITY.md documents the baseline (no recipe-maintainer parity corpus for wordpress). - nix/modules/bridge.nix: POLL_REPOS += recipe-maintainers/wordpress (!testme bridge enrollment; deploy to the cc-ci host follows separately after the in-flight /upgrade-all run - test-before-switch policy). Mirror recipe-maintainers/wordpress created + main synced to coopcloud upstream (adcd0e9f) with published tags. used-recipes.md gains 'wordpress weekly' in the orchestrator repo.
30 lines
2.4 KiB
Markdown
30 lines
2.4 KiB
Markdown
# Parity — wordpress
|
|
|
|
The recipe-maintainer corpus has **no** `recipe-info/wordpress/tests/` directory — wordpress was
|
|
not in the recipe-maintainer parity suite. This PARITY.md documents the Phase-2-style
|
|
recipe-specific tests + health_check as the parity-aligned baseline (enrolled 2026-08-03 on
|
|
operator request).
|
|
|
|
## Recipe-specific tests (≥2 beyond parity)
|
|
|
|
wordpress is a classic PHP CMS on mariadb. A fresh CI deploy serves the install wizard (the CI
|
|
env sets no `POST_DEPLOY_CMDS core_install`); the custom tier completes the wizard itself with
|
|
run-scoped credentials (`custom/_wp.py`) and then exercises the installed site's real APIs.
|
|
|
|
| cc-ci file | what's verified | rationale |
|
|
|---|---|---|
|
|
| `custom/test_health_check.py` | GET `/` → 200 or 302 (install-wizard redirect). | traefik → app wiring floor. |
|
|
| `custom/test_install_and_api.py` | Completes the install wizard (writes site options + admin user to mariadb), then asserts `/?rest_route=/` AND `/wp-json/` both return the configured site name. | Non-vacuous: the name only comes back if the install round-tripped through the DB. The two REST routes split failure layers: `?rest_route=` isolates "REST + DB", `/wp-json/` additionally proves the recipe's `.htaccess` rewrites are live. A DB-wiring failure is caught earlier by the installer's own "database connection" error, asserted in `_wp.ensure_installed`. |
|
|
| `custom/test_post_roundtrip.py` | §4.3 create-an-object + read-it-back: publish a post with a unique marker via **XML-RPC** `wp.newPost` (admin user/pass), read it back via the **public REST API** (`/wp/v2/posts/<id>`, title must contain the marker), then fetch the public permalink `/?p=<id>` and assert the marker in the served HTML. | The marker round-trips app → mariadb → app across three distinct subsystems (XML-RPC write, REST read, themed HTML render). A post that didn't persist, a broken DB, or a wedged PHP fails at the layer that broke. |
|
|
|
|
## Backup data-integrity (P4)
|
|
|
|
The recipe stores content in the `wordpress_content` volume + mariadb; backup-capable detection is
|
|
automatic (compose.yml `backupbot.backup` labels via the standard recipe mechanism). Lifecycle
|
|
overlays not yet authored — catch-up if backup data-integrity proves needed for this recipe.
|
|
|
|
## Playwright (P6)
|
|
|
|
Not authored. The install + post round-trip is API-driven; a Playwright pass over wp-admin would
|
|
add browser coverage of the dashboard. Follow-up if wanted.
|