Leaner, steadier PHPUnit runs for upcoming releases

Welcome!

The WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:

Found a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.? Create a ticket in the bug tracker.

Want to contribute? Get started quickly with tickets marked as good first bugs for new contributors or join a bug scrub. There’s more on the reports page, like patches needing testing, and on feature projects page.

Other questions? Here is a detailed handbook for contributors, complete with tutorials.

In recent years, the CI load across coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. WordPress GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/ repos increased as the project evolved. This is normal for an active project.

But, the load can be especially high when running the full PHPUnit matrix at once on many PRs, such as during a release with many backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. branches. Cases like this mean the number of jobs can strain the capacity of the system.

Ahead of 7.1, we’ve landed a round of trims and reliability fixes aimed at increasing capacity and running leaner while ensuring quality checks still run.

This CI work builds on the test-suite optimization work from many contributors in the past.

Two key changes

Trimmed the PHPUnit matrix to boundary PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher versions (#12719 on trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision., #12720 for 7.0). Full PHP coverage kept, redundant database combinations dropped. Per run: ~52% fewer jobs and ~54% fewer job-minutes.
Fetch the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ build once per run (#12701) instead of once per job, plus bounded retries on Docker image pulls (#12703). Runs needing a rerun to go green roughly halved, from ~68% to ~36%.

Source: measured per run from the GitHub Actions APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. (job counts and durations, and rerun counts) across comparable runs before / after the changes.

Next up

Trim the 6.8 matrix (#12726).
Pilot a dedicated larger-runner pool for use during release windows to help with concurrency issues (more on that in a future update).

Note: The PHPUnit tests themselves could be further tuned. The trims above cut job count, not job duration—so we could give more attention to the tests themselves to find more efficiency.

Thanks to contributions from adrianmoldovanwp, barry, garyj, @johnbillion, @jonsurrell, @jorbin, lucasbustamante, and @mukesh27.

Dennis Snell 1:47 am on July 30, 2026

Thanks @lancewillett — this is a welcome improvement.

It reminds me of a theme that keeps circulating: could we imagine moving tests out of PRs and instead running them on a schedule against trunk?

I think we might all have a lot of apprehension about the idea of merging when tests would later fail, but practically speaking, any failures would appear within an hour of merge and we could notify all committers who merged within the previous window that something failed and they should investigate.

This came up with the work @danluu was performing with fuzz-testing. Practically speaking, the only way we can maintain the policy of only merging when tests pass is by ensuring we don’t add test cases for known failures. I’ve seen concrete discussion about this in PRs and fixed issues as follow-up, because the author decided it was too complicated to fix the broken code highlighted by a new test. They leave out the tests that uncover the issues.

If we want to continually improve our quality, I think some comfort with a known list of failing tests might be useful. We could ensure that new contributions don’t add new breakage, but do so only when failures arise. In fact, we could freeze trunk when failures turn up. But we have an ocean of opportunity to remove fixes and if we could introduce failing tests first then we could lift a lot of the bottleneck in committing.

This seems like it would bring multiple benefits: lower CI usage, faster iteration speed, more liberty to add additional tests. Of course the drawback is a slower feedback cycle on defects, but the practical alternative seems to be hiding those defects.
Lance Willett 3:18 pm on August 12, 2026
Note for 7.0.3 on August 6, 2026: GitHub Actions was in a declared incident for the whole of the release window. At peak, 71% of workflow runs hit infrastructure failures, and webhook processing was throttled to roughly 15%, so many pushes never triggered a run at all.

For 7.0.4:
- Peak demand: 1,683 jobs running or waiting at once, against a 1,000-job account limit
- Went over 800 jobs for nine minutes, 13:20 to 14:54 UTC, then cleared
- Median job wait: 3 seconds. The slowest tenth spent about 1/3 of their life waiting
- Runs waiting on `wordpress-develop` stayed between 0 and 3 through the release window
The next release should give the first clean before-and-after.

Welcome!

Communication

Share this:

Site resources