fix(ci): get wp-env CI green on current GitHub runners#287
Merged
Conversation
…lugin The '.' entry in `plugins` mounts the checkout under its directory basename, while `mappings` also mounts it as `desktop-mode`. For any checkout whose folder is not named `desktop-mode` (git worktrees, or a clone under a different directory name) the plugin loads twice and fatals with "Cannot redeclare desktop_mode_cascade_deactivate_dependents()" during activation, so `wp-env start` aborts. The `mappings` entry already mounts the plugin as `desktop-mode`, and bin/setup-wp-env.sh activates it, so the '.' entry is redundant. Removing it makes `wp-env start` (and `npm run test:php:install` / `test:php`) work for every checkout directory name.
A recent `mariadb:lts` release (MariaDB 12.x) broke wp-env's database readiness. Without a healthcheck, the WordPress/CLI containers start before MySQL is ready, so `wp-env start` fails to bring up the tests environment: `service "tests-cli" is not running` in CI, and `Error establishing a database connection ... at tests-mysql` locally. @wordpress/env 11.0.0 adds a MySQL healthcheck (healthcheck.sh --connect --innodb_initialized) plus MARIADB_AUTO_UPGRADE=1 and `depends_on: condition: service_healthy`, which fixes startup against MariaDB 12.x. See WordPress/gutenberg#75046 Verified locally (with 11.7.0): env:start brings up all containers with mysql/tests-mysql healthy, and the full PHPUnit suite passes.
On cold CI runners, wp-env start's host-side downloadSources hangs on zip plugin sources (got/extract-zip): the zip extracts but the promise never resolves, the event loop drains, and the process exits 0 before bringing up the WordPress containers or recording the runtime. wp-env run then reports "Environment not initialized" and test:php:install fails. The core git source is unaffected; only zip sources hang. bin/setup-wp-env.sh (afterStart) already installs and activates gutenberg via wp-cli, so the gutenberg.zip entry was redundant. Dropping it removes the flaky host-side download while keeping gutenberg in the environment.
wordpress/plugin-check-action@v1 generates its own .wp-env.json that pulls the Plugin Check plugin from a zip source, hitting the same cold-runner wp-env start hang (and it overwrites any config we provide). Run Plugin Check in our own wp-env: a dedicated --config that mounts the built plugin and uses only the reliable core git source, with Plugin Check installed via wp-cli, parsing the JSON output so real errors still fail the build. Suppress wp_function_not_compatible_with_requires_wp via --ignore-codes: wp_enqueue_command_palette_assets() (WP 6.9) is called behind a function_exists() guard in includes/render/assets.php, which is the correct pattern, so the finding is a false positive.
e50171b to
3f4bac5
Compare
3f4bac5 to
e50171b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the wp-env CI breakage (PHPUnit + Plugin Check jobs) that started with the late-May 2026 GitHub runner image rollout, blocking #285. Node-agnostic (no Node pin).
Root cause
wp-env start'sdownloadSourcesextracts URL/zip sources withextract-zip(which uses yauzl). On Node 24.16.0 (a libuv 1.52.1 regression) that extraction hangs without leaving an active event-loop handle, sowp-env startsilently exits 0 without booting Docker;wp-env runthen reportsEnvironment not initialized. Bisected: Node 24.15.0 ✅, 24.16.0 ❌ (OS-independent). The ~May 2026 runner image bumpedactions/setup-node'24'past 24.15.0. The core git source is unaffected — only zip sources hang.Confirmed upstream: WordPress/gutenberg#78762 (issue) and #78828 (fix: replace
extract-zipwithadm-zip) — not yet in a released@wordpress/env.Changes
@wordpress/env10.39 → 11.7 — MySQL healthcheck for the MariaDBlts12.x readiness regression."."plugin entry in.wp-env.json. wp-env activates eachpluginsentry by its checkout-dir basename, so"."double-mounts the plugin on any dir not nameddesktop-mode(worktrees, local clones) and fatals withCannot redeclare …. Thedesktop-modemapping already mounts it.gutenberg.zipplugin source — this URL source is the one that hangswp-env starton Node 24.16+.bin/setup-wp-env.sh(afterStart) already installs+activates gutenberg via wp-cli (PHP installer, no yauzl), so the environment is unchanged and the fix needs no Node pin.wordpress/plugin-check-action@v1runs its ownsetup-node@… node-version: '24', so it always uses 24.16.0 and can't be pinned — it hits the same hang viaplugin-check.zip. Instead we mount the built plugin via a dedicated--config(core git source only), install Plugin Check via wp-cli, and parse the JSON so real errors still fail.ignore-codes=wp_function_not_compatible_with_requires_wpsuppresses the false positive for thefunction_exists()-guarded WP 6.9wp_enqueue_command_palette_assets()call.Verification
CI green on this branch (PHPUnit 8.3 / 8.4, Plugin Check, Lint·Types·Vitest).