The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: aduth <aduth@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: desrosj <desrosj@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Size Change: 0 B

Total Size: 2.45 MB

_{compressed-size-action}

I'm running into a few other Windows issues unrelated to the one I was originally trying to address here, so I'll have to spend some time working through those.

Slack discussion ongoing: https://wordpress.slack.com/archives/C02RQBWTW/p1762200484307419

Flaky tests detected in 48eb31e.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/19074321393
📝 Reported issues:

• [Flaky Test] should select the wrapper div for a group #71211 in /test/e2e/specs/editor/various/block-hierarchy-navigation.spec.js

Okay, this seems to be working now! I think the issues I was seeing yesterday were real Windows issues fixed separately by @t-hamano in #72960. There also seemed to be some Windows incompatibility in bin/check-licenses.mjs which I fixed in 7fb83a9.

The Windows & default static analysis checks are now passing (see Windows run log):

With the demonstration configuration reverted in 48eb31e, this should be ready for review now.

Consistent with #72506, these workflows only run on trunk for any combination of the above other than ubuntu-14.04 + 20. This should at least provide a faster feedback loop than currently waiting for builds to fail in wordpress-develop.

Personally, I feel like it'd probably be good to have at least one Windows build run as a required check in pull requests, so that we don't have to wait 'til it lands in trunk to know that it's an issue. But I'm also mindful of the goal of #72506 to cut down on the number of build variations.

Personally, I feel like it'd probably be good to have at least one Windows build run as a required check in pull requests, so that we don't have to wait 'til it lands in trunk to know that it's an issue. But I'm also mindful of the goal of #72506 to cut down on the number of build variations.

To be honest, I feel a php version (maybe the oldest supported php version) would actually be more important to run than windows. But it's very hard to decide, let's keep statusquo and monitor what failures we see on trunk more.

This didn't test the macOS runners, which are having some issues now that they're running on trunk, specifically around exceeding default memory limits (example).

Fix is proposed at #72980