Fix wp-env WordPress and phpunit version mismatch when no core version is set #43020
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.
What?
This adds a check in
wp-env
to query for the latest release version of WordPress before pullingtests/phpunit
test files. This replaces the previous default of pulling thetrunk
version of phpunit files when nocore
version is specified in.wp-env.json
.Why?
See investigation of the problem in Automattic/vip-decoupled-bundle#57 (comment), and related issue #41780 where phpunit changes were made.
Currently, when no
core
config is specified in.wp-env.json
,wp-env
uses WordPress source from thewordpress
docker image which is the latest WordPress release code.phpunit
code is pulled fromtrunk
. This can cause test failures when breaking changes are made intrunk
that are not yet present in WordPress' latest release.In this case in the current trunk version of WordPress,
wp-db.php
has been renamed toclass-wpdb.php
. During installation of WordPress for testing, phpunit includesclass-wpdb.php
. However,class-wpdb.php
does not exist on the latest release version of WordPress used bywp-env
. This causes an ugly failure during bootstrapping which is tricky to track down.This can be solved by specifying a
core
WordPress version, but for config files without a version there is always a possibility for a desync. The root problem is that WordPress' code is running from thewordpress
docker container and the WordPress version being used isn't yet known during phpunit file downloading.How?
These changes use the WordPress version check API before
tests/phpunit
cloning to determine the latest WordPress release version when no pinned version is specified. This makes a few assumptions:6.0.1
) corresponds with a tagged branch in https://github.com/WordPress/wordpress-develop.wp-env
will match the latest WordPress version when nocore
version is specified.It would be ideal if the code was able to determine the version of WordPress used by docker directly, but I'm not sure how this would be accomplished. The
tests/phpunit
directory download is setup during configuration before docker containers start running. Since we don't have direct access to the docker image, the code uses the assumptions above to pull the "correct" version of WordPress test files to match the release container. The code will also default totrunk
when the API fails to resolve, so the failure case should be the same behavior as before.Testing Instructions
For testing, I'm using the repository linked above where I discovered the issue. Here is a reproduction of the original problem using the current version of
wp-env
:Install the current latest version of
wp-env
:Clone the
vip-decoupled-bundle
repo for testingEdit
.wp-env.json
and remove the"core"
value to use the default WordPress version.Run
wp-env
provisioning:Install and run tests:
composer install composer run test
You should see the error documented in this comment resulting from a
test/phpunit
andWordPress
version mismatch.Using the files from this branch, here's how to test the fix:
In a separate directory, clone the
fix/wordpress-phpunit-version-mismatch
branch:Enter the
wp-env
package and install dependencies:cd packages/env/ nvm use npm install
From the
vip-decoupled-bundle
directory, recreate the enviroment with branch version ofwp-env
:Run tests again:
composer run test
The tests should now succeed, as the downloaded phpunit files now target WordPress 6.0.1.