wp-env: Add better default PHPunit settings, fix Xdebug, and update docs #50490
Conversation
This file contains 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
noahtallen
added
[Type] Bug
noahtallen
commented
May 9, 2023
|
Size Change: +69 B (0%) Total Size: 1.38 MB
ℹ️ View Unchanged
|
| @@ -183,6 +183,26 @@ Out of the box `wp-env` includes the [WordPress' PHPUnit test files](https://dev | |||
|
|
|||
| While we do provide a default `wp-tests-config.php` file within the environment, there may be cases where you want to use your own. WordPress provides a `WP_TESTS_CONFIG_FILE_PATH` constant that you can use to change the `wp-config.php` file used for testing. Set this to a desired path in your `bootstrap.php` file and the file you've chosen will be used instead of the one included in the environment. | |||
|
|
|||
| ## Using `composer`, `phpunit`, and `wp-cli` tools. | |||
|
|
|||
| For ease of use, Composer, PHPUnit, and wp-cli are available for in the environment. To run these executables, use `wp-env run <env> <tool> <command>`. For example, `wp-env run cli composer install`, or `wp-env run tests-cli phpunit`. You can also access various shells like `wp-env run cli bash` or `wp-env run cli wp shell`. | |||
There was a problem hiding this comment.
I worry that including wp-cli here makes it ambiguous. It feels like this is saying you should use wp-env run cli wp-cli <command>.
There was a problem hiding this comment.
That's a good point. I was trying to provide a search result if someone is looking to use wp-cli. And to actually use it, you have to do run cli wp... how do you think we should phrase it?
There was a problem hiding this comment.
Actually, I think this is fine. If you look at https://wp-cli.org, the official documentation has you using wp as the command. Anyone looking to use wp-cli will have that as the expectation I bet.
ObliviousHarmony
approved these changes
May 9, 2023
There was a problem hiding this comment.
Thanks @noahtallen, this tests really well. I tried it out both with the web server and CLI, and in both cases, the debugger worked perfectly. I really like how easy it was to set this up. Once I had the VS Code plugin installed it worked completely out of the box.
|
Flaky tests detected in 1cac185. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4931877789
|
ObliviousHarmony
approved these changes
May 9, 2023
packages/env/lib/init-config.js
Outdated
|
|
||
| /** | ||
| * Internal dependencies | ||
| */ | ||
| const { loadConfig } = require( './config' ); | ||
| const buildDockerComposeConfig = require( './build-docker-compose-config' ); | ||
|
|
||
| const { ValidationError } = require( './config' ); |
There was a problem hiding this comment.
This can be combined with the above require() (shouldn't the linter have caught this?)
| // support PHP 7 when the environment uses that version. By default, use the | ||
| // latest version. | ||
| if ( majorVer === 7 ) { | ||
| xdebugVersion = 'xdebug-3.1.6'; |
There was a problem hiding this comment.
What do you think about using the support version table from Xdebug's website? We can pair each PHP minor release with a compatible version of Xdebug and then fall back to plain xdebug to grab the latest.
There was a problem hiding this comment.
Something like:
// Map the PHP version to a compatible Xdebug version.
const versionMap = {
'7.2': 'xdebug-3.1.6',
'7.3': 'xdebug-3.1.6',
'7.4': 'xdebug-3.1.6',
'8.0': 'xdebug-3.2.1',
};
const xdebugVersion = versionMap[ `${ majorVer }.${ minorVer }` ] ?? 'xdebug';
There was a problem hiding this comment.
I think it might be useful in the future, but I don't know if it provides any value right now -- we either use current (3.2), or previous (3.1). Outside of that, we'd be on 2.x, which would require config changes that would be hard to maintain
ObliviousHarmony
approved these changes
May 10, 2023
|
np, glad we got it in a good spot! |
|
The documentation says to run : But it fails because the container user does not write permission: Full output: |
|
What does |
|
It might also be the case that the environment hasn't been updated since the permission changes! One caveat that just occurred to me is that, technically, changes to |
True... I guess the assumption was that those files won't change unless the config changes! |
This was referenced Dec 16, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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?
.htaccessmapping and increasing default upload size to 1GB.Before:
After:
How?
Adjusts the dockerfiles we generate! This also changes Xdebug such that it's not installed in the CLI environments.
Testing Instructions
PHP settings
.htaccessfile (following the documentation), and verify those upload sizes override the default valuesXdebug
npx wp-env start --xdebuggutenberg.phpTesting Instructions for Keyboard
Screenshots or screencast