recipe-maintainers/cc-ci
0
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
Files
f5c97117d6372a48c6ea0db433175461b118226e
cc-ci/tests/wordpress/PARITY.md
autonomic-bot d9a446cd36
Some checks failed
continuous-integration/drone/push Build is failing
Details
enroll(wordpress): test suite + bridge POLL_REPOS entry 
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.
2026-08-03 21:05:33 +00:00

2.4 KiB
Raw Blame History

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.