GitHub Actions updates and improvements for 6.9

[desrosj]

This ticket is for various updates and improvements for Core's GitHub Actions workflows.

Previously:

• 6.8 (#62221)
• 6.7 (#61564)
• 6.6 (#60733)
• 6.5 (#59805)
• 6.4 (#58867)
• 6.3 (#57865)
• 6.2 (#57572)

This adds a conditional statement that checks for debug mode to be enabled before outputting debug information.

Trac ticket: Core-63170.

Workflows runs triggered by push events will always run twice, with debug mode enabled the second time.

But I guess one downfall is that someone outside of the organization opening a pull request will never get to see the debug info because they do not have the required access to rerun a workflow. That could make this undesirable.

I also don't feel strongly on this. It was something I considered as a potential optimization. Let's get a few other opinions.

[desrosj]

In 60318:

Build/Test Tools: Add inline docs to explain the PHPUnit strategy.

In [59587], the PHPUnit workflow strategy matrix was expanded using the criteria of “all LTS versions supported by WordPress with >1% usage according to WordPress.org/stats,” but this was only mentioned in the commit message.

This adds some inline documentation to the explain that methodology for future reference.

See #63170.

[johnbillion]

In 60321:

Build/Test Tools: Finalise changes to the WordPress versions used during upgrade testing from the development branch.

See #63170

[desrosj]

In 60322:

Build/Test Tools: Update the upgrade testing matrix to reflect 6.8.

See #63170.

[johnbillion]

In 60323:

Build/Test Tools: Update the currently supported branch that's used to determine the frequency of scheduled tests of old branches.

See #63170

[johnbillion]

In 60324:

Build/Test Tools: Bump the default baseline version used for performance comparison tests.

See #63170

[johnbillion]

In 60326:

Build/Test Tools: Revert [60324] while memory exhaustion issues in the GitHub Actions workflows are investigated.

See #63170

• Clarifies the text about the last two releases
• Trims another version from the second group of upgrade tests because this should only test 6 versions as per the workflow description at the top

Originally, it was intended to test all 6.x versions, but now that there's 9 of them, I agree that it doesn't make sense.

The 5.x job below the one being edited tests uses the approach of testing all 5.x releases where the database version changed on the highest and lowest releases of each PHP major.

6.0's ​DB version changed from 5.9's, and every other 6.x version except 6.1, 6.2, 6.6, 6.8. We should either:

• Change the first job to test the last 3 major versions, and then test 6.0, 6.3, 6.4, and 6.5 in the second.
• Leave the first job testing the last 2 versions and test 6.0, 6.3, 6.4, 6.5 in the second one.

Both would need the inline docs to be updated accordingly matching the upgrade-tests-wp-5x-php-7x-mysql notes.

[johnbillion]

In 60340:

Build/Test Tools: Adjust the upgrade testing matrix for the 6.x branches so versions are tested only if a database version change was made.

Props desrosj, johnbillion

See #63170

Committed in https://core.trac.wordpress.org/changeset/60340

Committed in https://core.trac.wordpress.org/changeset/60341

[desrosj]

In 60346:

Build/Test Tools: Run PHPUnit test suite using MariaDB 11.8.

The latest LTS version of MariaDB (11.8) was released on June 8, 2025.

Though it does not yet account for the 1% of WordPress installs criteria currently documented in the workflow, the most recent LTS version should always be tested against.

Props johnbillion.
See #63170.

[desrosj]

In 60347:

Build/Test Tools: Monitor default themes for dependency updates.

There are currently 3 default themes with build processes: Twenty Twenty-One, Twenty Twenty, and Twenty Nineteen. This adds a configuration for each to the Dependabot configuration to ensure pull requests are opened when updates become available.

Because they have a low number of dependencies, they will all be updated in the same pull request to start. Groups can be configured later if this presents problems.

See #63170, #63170.

[desrosj]

In 60348:

Build/Test Tools: Commit changes to built theme files for PRs.

When there are uncommitted changes to versioned files in default themes, the theme testing workflow will now store the patch file required for the changes to be committed back to the pull request.

See #63170, #63171.

[desrosj]

In 60349:

Build/Test Tools: Create groups for bundled theme Dependabot PRs.

Follow up to [60347].

See #63170, #63171.

[desrosj]

In 60350:

Build/Test Tools: Only check for changes to versioned files once.

Because the theme testing workflow now stores a patch file with changes to versioned files, there is no need for the separate workflow to run and do the same when only theme files are updated.

Follow up to [60348].

See #63170, #63171.

[johnbillion]

In 60612:

Build/Test Tools: Add some missing permissions to the GitHub Actions workflows.

These permissions are not required for a public repo but are required for a private repo, for example a private fork.

Props johnbillion, desrosj

See #63170

https://core.trac.wordpress.org/changeset/60612

This adds additional test combinations to the workflow that tests the build process that run on Node.js versions 22 and 24.

22.x is the Active LTS version for Node.JS and scheduled to become Maintenance LTS in October when 24.x graduates to the Active LTS. Testing against these versions will help spot any potential compatibility issues that come up and can make upgrading in the future.

This pull request tests only the Core build process with these versions. This is an alternate approach to #9395.

This results in 12 additional jobs in the test matrix. These new jobs will only run within wordpress-develp, not within forks.

Trac ticket: Core-63170.

This adds additional test combinations to the workflow that tests the build process that run on Node.js versions 22 and 24.

22.x is the Active LTS version for Node.JS and scheduled to become Maintenance LTS in October when 24.x graduates to the Active LTS. Testing against these versions will help spot any potential compatibility issues that come up and can make upgrading in the future.

This pull request tests both the Gutenberg and Core build processes with these versions. This is an alternate approach to #9399.

This results in 24 additional jobs in the test matrix. These new jobs will only run within wordpress-develp, not within forks.

Trac ticket: Core-63170.

While the -latest alias is no longer used in Core workflows (see Changeset-59720), GitHub has ​begun rolling out a change to their MacOS runner images that tags the macos-15 as macos-latest instead of macos-14.

Similarly, the windows-latest alias will be updated to point to windows-2025 in ​during the month of September.

This changes the workflows running on MacOS and Windows images to use the versions that will now be considered the "latest" versions.

Trac ticket: Core-63170.

[johnbillion]

In 60624:

Build/Test Tools: Add some further missing permissions to the GitHub Actions workflows.

These permissions are not required for a public repo but are required for a private repo, for example a private fork.

Props johnbillion, desrosj

Follow-up to r60612.

See #63170

https://core.trac.wordpress.org/changeset/60624

[johnbillion]

In 60625:

Build/Test Tools: Ensure a change to the Node version always runs relevant test workflows.

Props johnbillion, desrosj

See #63170

https://core.trac.wordpress.org/changeset/60625

This updates workflows to all use the same notation for tag version ranges. It removes the usage pattern where [0-9]+.[0-9] is allowed and subsequently partly disallowed, replacing it with the more explicit and readable notation of inclusive ranges.

[desrosj]

In 60626:

Build/Test Tools: Use newer runner images for MacOS & Windows.

GitHub is in the process of deploying an update to their MacOS and Windows GitHub Actions runners that changes the -latest tag to point to macos-15 and windows-2025. Once this completes, the number of available runners for the previous version will decline and could result in longer queues.

This updates the build process testing workflow to test against these new versions.

Prop johnbillion.
See #63170.

Merged in https://core.trac.wordpress.org/changeset/60626.

[johnbillion]

In 60628:

Build/Test Tools: Adjust various jobs names in the GitHub Actions workflows to remove duplication and improve grouping in the UI when they run.

Props desrosj, mukesh27, johnbillion

See #63170

https://core.trac.wordpress.org/changeset/60628

https://core.trac.wordpress.org/changeset/60628

https://core.trac.wordpress.org/changeset/60628

The main aim here is to reduce the chance of unnecessary workflows running when changes are not made to src files. As an example, a change to a phpunit test file currently triggers the e2e tests, the performance tests, and the build process testing, all of which are unnecessary.

[desrosj]

In 60692:

Build/Test Tools: Update third-party GitHub Actions.

This updates the following third-party actions to their latest versions:
actions/checkout from 4.2.2 to 5.0.0
shivammathur/setup-php from 2.32.0 to 2.35.3
actions/setup-node from 4.3.0 to 4.4.0
ramsey/composer-install from 3.1.0 to 3.1.1
actions/cache from 4.2.3 to 4.2.4
actions/download-artifact from 4.2.1 to 5.0.0
codecov/codecov-action from 5.4.0 to 5.4.3
slackapi/slack-github-action from 2.0.0 to 2.1.1

See #63170.

[desrosj]

In 60767:

Build/Test Tools: Add branch filtering to upgrade test workflow.

The upgrade testing workflow is only meant to run from trunk. When a pull request as any other BASE branch, the workflow should not run.

See #63170.

It looks like r60612 and r60624 will need to be backported to older branches.

When working on a ticket that backported changes to older branches, I noticed that the ​Check Built Files workflow was failing for the 6.8 branch with the following error:

Invalid workflow file: .github/workflows/check-built-files.yml#L42
The workflow is not valid. .github/workflows/check-built-files.yml (Line: 42, Col: 3): Error calling workflow 'WordPress/wordpress-develop/.github/workflows/reusable-check-built-files.yml@trunk'. The nested job 'update-built-files' is requesting 'contents: read', but is only allowed 'contents: none'.

The same was true with the upgrade develop testing workflow:

Invalid workflow file: .github/workflows/upgrade-develop-testing.yml#L54
The workflow is not valid. .github/workflows/upgrade-develop-testing.yml (Line: 54, Col: 3): Error calling workflow 'WordPress/wordpress-develop/.github/workflows/reusable-upgrade-testing.yml@trunk'. The nested job 'upgrade-tests' is requesting 'contents: read', but is only allowed 'contents: none'.

All of the others seem to be working as expected. These two workflows were introduced during the 6.8 cycle, so thankfully this does not need to be backported further. @johnbillion I'm going to add this to the list we have started for a GitHub Actions page in the handbook.

Trac ticket: Core-63170

[desrosj]

In 60773:

Build/Test Tools: Add some missing permissions to the GitHub Actions workflows.

These permissions are not required for a public repo but are required for a private repo, for example a private fork.

Merges [60612], [60624] to the 6.8 branch.

Props johnbillion, desrosj.
See #63170

Merged in r60773.

This has been supported since ​https://github.com/WordPress/wpdev-docker-images/pull/151.

Trac ticket: Core-63170

Merged in r60774.

[johnbillion]

In 60801:

Build/Test Tools: Add some missing permissions to the legacy GitHub Actions workflows that are used by older branches.

These permissions are not required for a public repo but are required for a private repo, for example a private fork.

Follow-up to [60612].

See #63170

For the 6.7 branch:

• Deletes unnecessary workflows
• Trims the unit testing matrix to the highest and lowest supported version of each major PHP branch.

​GitHub recently added support for YAML anchors and aliases in workflow files. This means we can reduce duplication in the branches and paths mappings.

One thing that I think will block this being merged for now is that ​Actionlint is yet to support this feature. Let's test it out anyway.

Work in progress.

This swaps out db-type and db-version inputs for a more explicit db-image which contains values such as mysql:8.0 and mariadb:10.3.

The idea behind this is that we can be more explicit with version support differences between MySQL and MariaDB without having to maintain confusing inclusion and exclusion rules that are hard to read. As someone who is not overly familiar with the available versions of each of the two, I find the matrices confusing. This should help a lot.

I've started on install-testing.yml and local-docker-environment.yml too -- which both call reusable-support-json-reader-v1.yml -- but I need to think more about how these should work and whether the format of .version-support-mysql.json needs updating. My original idea is that this file would be updated to include a separate list of supported versions for MySQL and MariaDB.

[johnbillion]

In 61081:

Build/Test Tools: Remove duplication from some GitHub Actions workflow names.

Props desrosj, mukesh27, johnbillion

See #63170

https://core.trac.wordpress.org/changeset/61081

[johnbillion]

In 61082:

Build/Test Tools: Unify the notation used for version ranges when filtering workflow triggers by branch and tag.

Props jorbin, desrosj, johnbillion

See #63170

https://core.trac.wordpress.org/changeset/61082

This adds a check to confirm a pull request is open before leaving a comment with the instructions for testing in Playground. In scenarios where a ​pull request is closed before the workflow runs, comments can be left on closed PRs.

Props @jeffpaul for spotting this on #10280.

Trac ticket: Core-63170.

[desrosj]

In 61135:

Build/Test Tools: Only open pull requests need testing instructions.

This adds some logic to avoid leaving automated comments with instructions to test in Playground when the pull request has been closed.

Props jeffpaul.
See #63170.

Fixed in r61135.

[wildworks]

This ticket was brought up in today's 6.9 bug scrub.

This is an iteration ticket that is added for each major release, and since the RC1 release is coming soon, I think it should be fine to close it now. If necessary, we can create a new ticket for 7.0.

[desrosj]

In 61209:

Build/Test Tools: Update third-party GitHub Actions.

This updates the following third-party GitHub Actions:

• actions/github-script from 7.0.1 to 8.0.0.
• actions/checkout from 4.2.2 to 5.0.0.
• actions/setup-node from 4.3.0 to 6.0.0.
• actions/upload-artifact from 4.6.2 to 5.0.0.
• actions/cache from 4.2.4 to 4.3.0.
• actions/download-artifact from 5.0.0 to 6.0.0.
• shivammathur/setup-php from 2.35.3 to 2.35.5.
• codecov/codecov-action from 5.4.3 to 5.5.1.

See #63170.

[desrosj]

In 61225:

Build/Test Tools: Revert [61018].

[61018] was a good way to quickly limit the number of jobs spawned by the PHPUnit test workflow during the time leading up to beta releases for the 6.9 release, but this approach is not sustainable. This reverts that commit so a better long term solution can be explored in #64083.

See #63170, #64083.

[desrosj]

Reopening for [61225] to be considered for backporting to the 6.9 branch.

[peterwilsoncc]

[61225] looks good to backport.

[peterwilsoncc]

In 61256:

Build/Test Tools: Revert [61018].

[61018] was a good way to quickly limit the number of jobs spawned by the PHPUnit test workflow during the time leading up to beta releases for the 6.9 release, but this approach is not sustainable. This reverts that commit so a better long term solution can be explored in #64083.

Reviewed by peterwilsoncc.
Merges [61225] to the 6.9 branch.

See #63170, #64083.

[peterwilsoncc]

Sorry @desrosj, I forgot to props you above as the original committer. I've added it in the make/core admin.

Closing this off now the backport is complete.

https://core.trac.wordpress.org/changeset/61736

To test this PR, I implemented GitHub's filter-glob semantics and replayed the last 12 months of trunk commits (1,800 of them) through both the old and new filter sets. The numbers below are measured rather than estimated.

_Transparency in AI usage: I used Claude Code Opus 5 to review, test, and craft this reply._

The approach holds up well: this change avoids roughly 790 workflow runs per year. The phpunit-test-file example accounts for 512 of those on its own, across the e2e, performance, and build-process workflows.

---

Four things worth changing before you merge.

### 1. Rebase first, and keep the entries trunk has since added

The PR currently shows as conflicting, and the branch is 1,691 commits behind trunk. ece2d364b4 ("Improve GitHub Actions path filtering rules", See #64227) has since added tools/gutenberg/** and tools/vendors/** to seven of these workflows. Those entries do not exist on this branch, so a conflict resolution that takes the branch side will silently drop them:

check-built-files          .github/workflows/reusable-check-built-files.yml
                           tools/gutenberg/**, tools/vendors/**
end-to-end-tests           tools/gutenberg/**, tools/vendors/**
javascript-tests           tools/gutenberg/**, tools/vendors/**
local-docker-environment   tools/gutenberg/**, tools/vendors/**   (push)
performance                tools/gutenberg/**, tools/vendors/**
test-build-processes       tools/gutenberg/**, tools/vendors/**
phpunit-tests              tests/phpunit/multisite.xml

Separately, becfe55789 already landed the phpunit.xml.dist entry and the "This files affect"→"These files affect" fix, so those two hunks become no-ops after a rebase.

### 2. phpunit-tests.yml, end-to-end-tests.yml, and performance.yml need tools/local-env/**

reusable-phpunit-tests-v3.yml runs every PHPUnit invocation through node ./tools/local-env/scripts/docker.js, plus npm run env:start and npm run env:install. The e2e and performance workflows reach the same scripts through their own reusable workflows. **.js matched them; src/**.js does not.

Only 7 commits touched tools/local-env/ in the last 12 months, but 6 of those touched nothing under src/, so they would now run no PHPUnit at all. Two examples: 4b4e950756 ("Ensure all db WP-CLI commands work", docker.js) and 4ac482fd97 ("Explicitly enable pretty permalinks on the local development environment", install.js). Both change the harness the tests run in.

# The test runner executes through these scripts. Changes could affect the outcome.
      - 'tools/local-env/**'

Worth noting the e2e and performance lists keep tools/webpack/**, and local-docker-environment.yml already uses tools/local-env/**, so the pattern is established.

### 3. coding-standards.yml needs Gruntfile.js

The JavaScript job runs grunt jshint, and the Gruntfile defines jshint.grunt = { src: ['Gruntfile.js'] }. The other four JSHint targets (tests, themes, media, core) all resolve to tests/qunit/** or paths under src/, so Gruntfile.js is the only JSHint input this drops.

It changed 46 times in the last 12 months, and accounts for 18 of the 33 commits this workflow would newly skip. Every other workflow touched here already lists it.

### 4. test-build-processes.yml is missing the root *.php entry

Five siblings received - '*.php'; this one narrowed to src/**.php alone. It matters most here: the Gruntfile's copy:files task copies root wp-config-sample.php into the build directory, and this workflow's job is verifying the src-to-build copy across a directory: ['src','build'] matrix.

### Nit/typo

"These files configures JSHint" should be "configure" in coding-standards.yml.

### Questions

Adding src/**.json to end-to-end-tests.yml and performance.yml widens them rather than narrowing: 189 files now trigger those two workflows that previously did not, being 119 block.json files under src/wp-includes/ and 69 theme.json files under src/wp-content/. Defensible on the merits, since both affect rendering and performance, but it is the opposite of the stated goal and is not mentioned in the description. Intentional?

src/SECURITY.md in phpunit-tests.yml matches nothing, since the file lives at the repository root, unlike src/license.txt on the line above. Pre-existing rather than something this PR introduces, but you are already adding root-file patterns a couple of lines below.

Lastly, are any of the previous code comments from other reviewers still valid?