Fix Plugin Check CI: WP-CLI token fix done; wp-env regression blocked upstream

[ilicfilip]

Status: token issue FIXED ✅ — wp-env startup BLOCKED on upstream bug ⚠️

This PR fixes the test (WordPress.org Plugin Check) job on develop. There were two sequential failures. The first is fixed and verified; the second is a confirmed upstream bug with a maintainer-tracked fix in progress. Waiting on upstream.

---

Part 1 — FIXED & verified: GitHub token rejected by WP-CLI's Composer

Symptom: wp package install wp-cli/dist-archive-command failed with:

Failed to get composer instance: Your github oauth token for github.com contains invalid characters: "***"

Root cause: GitHub's Actions token format is now ghs_<id>_<base64url-JWT> (contains hyphens). The Composer bundled inside the stable WP-CLI phar uses an old validation regex that rejects hyphens — composer#12076. The token reaches WP-CLI via COMPOSER_AUTH (exported globally by setup-php), which WP-CLI reads before GITHUB_TOKEN, so clearing GITHUB_TOKEN had no effect.

Fix (committed here): sudo -E $(which wp) cli update --nightly --yes before the install. The nightly WP-CLI bundles a Composer with relaxed token validation. sudo is needed because setup-php installs the phar to a root-owned path.

Verified in CI: Success: Updated WP-CLI to the latest nightly release. → Success: Package installed. → Success: Created progress-planner.zip. This part works — keep it.

---

Part 2 — BLOCKED upstream: wp-env silently fails to start in plugin-check-action

Symptom (current failure): after the token fix, the job fails later inside wordpress/plugin-check-action. wp-env start --update reports success (Command completed after 1 attempt(s)) but never actually boots Docker, so the next CLI call fails:

- Reading configuration.            ← completes, then wp-env exits 0 WITHOUT booting Docker
✖ Environment not initialized. Run `wp-env start` first.

This is a confirmed upstream bug — WordPress/gutenberg#78762 (status: In Progress), originally surfaced via WordPress/plugin-check-action#579.

Root cause (per the maintainers' bisection in #78762): it is not a @wordpress/env version change — the packages/env/ source is byte-identical across 11.5.0 → 11.6.0 → 11.7.0 (only CHANGELOG.md/README.md differ). It is a latent wp-env bug exposed by the Node.js 24.15 → 24.16 bump (libuv 1.51 → 1.52.1) in the new GitHub Actions ubuntu-24.04 runner image. wp-env's URL-source download path extracts zips via extract-zip → yauzl → zlib.InflateRaw; on Node 24.16 the extraction of a large zip (WP core, and plugin-check.zip with 3589 entries) stalls and never resolves. With nothing left on the event loop, Node drains it and exits 0 cleanly → Docker is never started.

The trigger is conclusively the URL-plugin entry the action always injects into .wp-env.json (https://downloads.wordpress.org/plugin/plugin-check.zip). The maintainers' bisection ruled out the testsEnvironment dual-env path and the --update flag; removing the URL source (installing plugin-check via wp-cli after start) makes all jobs green on both runner images.

This is develop-only (no plugin-check.yml on main) and unrelated to the v1.9.1 sync. It is not fixable from our side by pinning @wordpress/env: the versions are identical (so the pin is a no-op), and the action re-installs @wordpress/env unpinned itself anyway (overriding any pin) — both confirmed in this PR's commit history.

Decision: wait for upstream

The fix-in-progress upstream is to replace extract-zip with adm-zip (gutenberg#78828) plus a post-start "is Docker actually up?" verification. Once that ships in a new @wordpress/env release (and/or plugin-check-action stops using a URL plugin), bumping the action will fix us with no workaround. We are waiting on that rather than maintaining an inlined copy of the action.

• Immediate unblock workaround, if ever needed: inline the action's steps, pin Node to 24.15.0, drop the URL-plugin entry and install plugin-check via wp-cli after wp-env start — reference diff WordPress/performance#2496. (The action pins Node to major 24 internally, so an external Node pin only takes effect if we stop using the action.)

Next steps for whoever picks this up

1. Watch gutenberg#78762 / gutenberg#78828 for a released fix, then bump wordpress/plugin-check-action to the fixed tag.
2. If CI needs unblocking before then, either apply the #2496-style inline workaround or set continue-on-error: true on the test job temporarily.

Commits in this PR

• WP-CLI nightly update (+ sudo) — the working token fix, keep
• @wordpress/env@11.5.0 pin attempt — no-op (versions are byte-identical, and the action re-installs latest); can be dropped
• (earlier setup-php pin / unset GITHUB_TOKEN commits — superseded, ineffective)

Test plan

• Token error resolved (wp package install succeeds)
• wp-env environment starts — blocked on gutenberg#78762

[github-actions]

Test on Playground
Test this pull request on the Playground
or download the zip

[github-actions]

✅ Code Coverage Report

Metric	Value
Total Coverage	31.62% 📉
Base Coverage	31.62%
Difference	📈 0.00%

⚠️ Coverage below recommended 40% threshold

🎉 Great job maintaining/improving code coverage!

ℹ️ About this report

• All tests run in a single job with Xdebug coverage
• Security tests excluded from coverage to prevent output issues
• Coverage calculated from line coverage percentages