-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use git for wp-env
's default WordPress version
#42826
Conversation
wp-env
's default WordPress version to use gitwp-env
's default WordPress version
@@ -33,7 +34,7 @@ const md5 = require( '../md5' ); | |||
* Base-level config for any particular environment. (development/tests/etc) | |||
* | |||
* @typedef WPServiceConfig | |||
* @property {?WPSource} coreSource The WordPress installation to load in the environment. | |||
* @property {WPSource} coreSource The WordPress installation to load in the environment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is never null
now that we default to a git source when the user doesn't provide one. As a result, there is probably more code to cleanup, but everything should work correctly in the meantime.
Size Change: 0 B Total Size: 1.27 MB ℹ️ View Unchanged
|
4ad746f
to
6eb5965
Compare
6eb5965
to
396dbaf
Compare
|
||
const detectedLocalConfig = | ||
Object.keys( { ...baseConfig, ...overrideConfig } ).length > 0; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The lines above were just moved from lower in the file so that the information is available for the following if statement
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Went through the testing plan, and I can see version "6.1-alpha-53845" shown in wp-admin and in the filesystem in ~/wp-env/<hash>/WordPress/wp-includes/version.php
👍🏻
Do you think it'd be worth adding the ability to specify where to download WordPress from in the future? I'm thinking of a git repo/committish. I know we can change the version using wp cli
, but perhaps this could make it easier to use custom forks? Food for thought :)
You can actually already do this! All of the download sources, including plugins, support The only caveat with the test files is that those will still download from |
Yeah, I think this would be the expected version for Gutenberg! I wasn't very clear in my test plan, but it's also worth testing on a different plugin which doesn't manually specify which WordPress version to use, since this PR aims to change the default version |
6933f89
to
2d0f9b2
Compare
…ess git repository
2d0f9b2
to
df4fc53
Compare
What?
Up to now, the default WordPress version installed by
wp-env
is whatever Docker provides. This version is used when there is no core version specified inwp-env.json
. We have no control over what Docker provides, and it is difficult to know what version it installs before it installs it. This causes problems when we wish to install a matching version of the phpunit test code, for example.In this change, we now default to
WordPress/WordPress#$latest_version
instead, where$latest_version
is pulled from https://api.wordpress.org/core/stable-check/1.0/.There are two cons, but I think they are pretty minor:
npx wp-env start
now includes an extra API request towordpress.org
. In my very rough testing, this only adds about 300ms at most.Why?
When trying to install a matching version of the phpunit test code, we need a WordPress version already available so that we can see which version is installed. However, Docker installs WordPress inside the container, which is difficult to read. There is also no guarantee it will always be up-to-date as we need it to be.
Controlling the WordPress version ourselves means that users will get WordPress updates more quickly. For example, when the WordPress update is published,
wp-env
will immediately start using it because our "cache" will immediately invalidate as the version in the configuration changes.It also means that there will always be a
version.php
file for our "version-matcher" code to use for phpunit test code downloads.For some extra context, I first noticed this issue trying to integrate the phpunit updates in
wp-env
in a different repository. I discovered that a filename was changed in core WordPress -- and this change was present in the test library, but not in WordPress itself. This is because the test code downloader usestrunk
tests when no core source is given. But Docker installs the latest stable version (6.0.1) when no core source is given. So there was a mismatch.This PR fixes that bug, since there is now a core source that our test code downloader can match in the default case.
How?
WordPress/WordPress#...
, with a ref pointing at the latest version from step one. That repo has tags for every published WordPress version, matching the format from the stable check API.Testing Instructions
path/to/gutenberg/packages/env/bin/wp-env start
for a plugin which has no core source.~/.wp-env/$hash/
Also verify that there is no change for a repo like Gutenberg, which specifies a core source already.