-
Notifications
You must be signed in to change notification settings - Fork 374
Blueprints: Resolve the latest WordPress version from the API instead of assuming it's the same as the last minified build #2027
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
Blueprints: Resolve the latest WordPress version from the API instead of assuming it's the same as the last minified build #2027
Conversation
… of assuming it's the same as the last minified build
WordPress builds package, breaking `@wp-playground/cli` in #2026
This PR updates the setSiteLanguage step to pull the latest/bets WordPress version details from api.wordpress.org/core/version-check/1.7?channel=beta
instead of implicitly assuming the latest version is the same as that of
the latest minified web build. It reuses the Playground CLI
resolveWordPressRelease function, bringing us closer to having zero
CLI-specific logic.
## Testing instructions
* CI tests
* Run Playground CLI via `bun packages/playground/cli/src/cli.ts server`
and confirm WordPress is still being downloaded without errors.
|
The remaining unit test failure is intermittent. Let's merge! |
|
We'll still need to release the npm packages to resolve the issue in As for the post-release smoke tests, @psrpinto – would you be interested in building an automated workflow? I remember the work you've done on the mock npm registry and it would be really helpful here. The release workflow could first publish the built artifacts to such a local/mock registry, and make sure those packages can still be installed, libraries – imported, and binaries – executed. |
Sure! I've added myself to the list. Once merged, I will proceed. |
|
@adamziel I was planning on documenting how to/making it easier to publish packages to a local npm registry this week. I will start by opening an issue. Once that's done, I can look into leveraging that to run some tests. |
## Motivation for the change, related issues I need to run [this workflow](#2027 (comment)), as well of the future ones. ## Implementation details Add myself to the `if` instructions of the GitHub workflows. ## Testing Instructions (or ideally a Blueprint) Nothing testable. Once merged, I will be able to run https://github.com/WordPress/wordpress-playground/actions/workflows/publish-npm-packages.yml and others.
Draft for that here: |
#1987 created a dependency between the
@wp-playground/blueprintspackage and the@wp-playground/wordpress-buildspackage breaking@wp-playground/cli– see #2026This PR updates the setSiteLanguage step to pull the latest/best WordPress version details from api.wordpress.org/core/version-check/1.7?channel=beta instead of implicitly assuming the latest version is the same as that of the latest minified web build. It reuses the Playground CLI resolveWordPressRelease function, bringing us closer to having zero CLI-specific logic.
Follow-up work
Invent an ESLint rule to prevent further dependencies on
@wp-playground/wordpress-buildsTesting instructions
bun packages/playground/cli/src/cli.ts serverand confirm WordPress is still being downloaded without errors.cc @swissspidy @bgrgicak