Repair wp/6.7 branch Actions: Replace wp-env's database check with a MariaDB health check - #83864

Part of #82783.

What?

Ports #75046 ("wp-env: Fix MySQL startup race condition causing database connection errors") to this branch's wp-env:

• The database services (mysql and tests-mysql) share a health check (MARIADB_HEALTHCHECK), plus MARIADB_AUTO_UPGRADE so existing databases get the user healthcheck.sh needs. It runs MariaDB's healthcheck.sh --connect --innodb_initialized only when the data directory has .my-healthcheck.cnf and the image has healthcheck.sh. Otherwise it pings the server over TCP on 127.0.0.1 with mariadb-admin (11.0 and newer only ship this name) or mysqladmin (versions before 10.4 only ship this name).
• wordpress and tests-wordpress depend on their database with condition: service_healthy, so Docker Compose only starts WordPress once MariaDB is ready.
• The wp db check connection check, its 30-second retry loop and the extra 4-second sleep are removed from wp-env start.
• wp-env start starts mysql and tests-mysql together, and wp-env clean starts only the database(s) it resets.
• packages/env/CHANGELOG.md gets trunk's entry, extended to describe the fallback ping, with links to wp-env: Fix MySQL startup race condition causing database connection errors #75046 and Env: Add an option to choose the MariaDB version #83751.
• The README's note about wp db commands with a mariadbVersion older than 11.4 now says that wp-env start and WordPress itself are not affected, since wp-env start no longer runs wp db check.

Why?

wp db check runs mariadb-check in the cli container. The client in the current wordpress:cli image (MariaDB 11.8) requires TLS by default, and WP-CLI runs it with --no-defaults, so nothing can turn that off. Any database without TLS, which means every MariaDB release before 11.4, fails with TLS/SSL error: SSL is required, but the server does not support it and stops wp-env start.

This branch pins MariaDB 11.4, which has TLS, so it isn't failing today. This brings its startup in line with trunk, which removed wp db check for the same readiness problem, and keeps wp-env start working if the pin or the CLI image changes.

How?

The changes follow #75046 hunk for hunk, adapted to this branch's file layout (commands/start.js, commands/clean.js and wordpress.js), except the health check command, which is #83751's runtime check (at e02f866).

#75046's health check runs healthcheck.sh unconditionally, which doesn't work for every version the mariadbVersion option allows. MariaDB 10.2 and 10.3 images ship the script without the healthcheck user, images built before 2022 and older patch tags (such as 10.5.8 and 10.6.4) have no script at all, and a data volume written by a newer image keeps .my-healthcheck.cnf when an older image without the script runs on it. Those databases would never become healthy, so WordPress would never start. The check is decided at runtime rather than by image tag, so every version, including lts and latest, uses the same check.

#75046's two compose-builder tests are ported, and new tests run the health check command through /bin/sh with stub tools for each path (skipped on Windows).

Verified locally: this branch's 11.4 pin becomes healthy through healthcheck.sh, and "mariadbVersion": "10.3" through the ping.

Use of AI Tools

This PR was created by Claude Code under my supervision. All code should be treated as AI-produced and not yet reviewed by a human until this PR is marked Ready for Review.

🤖 Generated with Claude Code