GitHub Actions updates and improvements for 7.2

[desrosj]

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

Previously:

• 7.1 (#64893)
• 7.0 (#64227)
• 6.9 (#63170)
• 6.8 (#62221)
• 6.7 (#61564)
• 6.6 (#60733)
• 6.5 (#59805)
• 6.4 (#58867)
• 6.3 (#57865)
• 6.2 (#57572)

This expands the conditional checks attached to GitHub Actions workflow jobs to further limit when pull_request events spawn workflow runs within forks and private mirrors.

When the repository is not WordPress/wordpress-develop, the workflow now must be triggered by a pull request that is marked ready for review for all private repositories.

In case someone wishes to run workflows in a draft PR, the Draft Workflow Runs label could be added to the pull request and all future workflows will run.

Trac ticket: Core-65845.

## Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code

Used for creating the initial PR. All changes were manually reviewed by me.

With performing 7.1 branching targeted for today, I'm going to wait until after that occurs to commit this. I've changed the Trac ticket reference in the PR description accordingly.

[desrosj]

[63183] was intended for this ticket, but had a typo in the See line of the commit message.

This should be considered for backporting through the 4.7 branch.

Does the new label need to be created first? Draft Workflow Runs doesn't exist yet in either repo I checked.

the workflow now must be triggered by a pull request that is marked ready for review for all private repositories

Marking a draft ready for review won't start a run

With no types: list under pull_request:, a workflow runs only for opened, synchronize, and reopened. Per ​the docs:

By default, a workflow only runs when a pull_request event's activity type is opened, synchronize, or reopened.

None of the twelve workflows here set types:. Marking a draft ready fires ready_for_review; adding a label fires labeled. Neither is on that list, so neither starts a run.

So in a private repo or fork: open a draft, nothing runs (intended); push, nothing runs (intended); mark it ready, still nothing. The first run waits for the next subscribed event: a push, an "Update branch", or a reopen.

props-bot.yml already covers this, and its comment names the catch:

# GitHub does not allow filtering the `labeled` event by a specific label.
  # However, the logic below will short-circuit the workflow when the `props-bot` label is not the one being added.
  types:
    - opened
    - synchronize
    - reopened
    - labeled
    - ready_for_review

Adding ready_for_review looks simple. labeled is the harder one. It fires for every label and can't be narrowed at the trigger, though ​the short-circuit props-bot uses is one way around that.

---
_{Adversarial review · <code>claude-opus-5</code>}

Committed in r63183.

This changes the logic that controls when a cancelled notification is posted to Slack so that only the second run is reported as cancelled to avoid too many notifications from being posted.

Additionally, there is new logic added to distinguish workflows that time out from cancelled ones. The available GitHub Actions functions and contexts to not make a timed_out outcome available, but the REST API does.

Trac ticket: Core-65845.

## Use of AI Tools
Claude Code was used to create the initial PR.

In r59983, a new workflow was introduced to commit changes to tracked files that were not included in a given pull request.

It's been nearly 2 years, and the workflow has not proven as useful as originally hoped. Additionally, all workflows that run the build script are already configured to fail when there are untracked changes by running git diff --exit-code. The only unique thing that the check-built-files.yml workflow runs is grunt precommit:css.

This removes the related workflows to avoid needlessly consuming GH Actions minutes and adds the grunt precommit:css task to the reusable-test-core-build-process.yml workflow file.

Trac ticket: Core-65845.

## Use of AI Tools
None.

[desrosj]

In 63310:

Build/Test Tools: Distinguish between cancelled and timed out workflow runs.

GitHub Actions expressions and contexts do not currently expose the details about a workflow run necessary to determine whether a workflow has timed out. Instead, all timed out runs are considered cancelled. However, the REST API does return a timed_out conclusion in this scenario.

This creates a new job for the timed_out conlclusion and adjusts the logic for cancelled Slack notifications to provide more useful notifications.

Props lancewillett.
See #65845.

The part limiting notifications to only the second run was committed in r62740. The timed_out logic was committed in r63310.

[desrosj]

In 63313:

Build/Test Tools: Make SLACK_GHA_TIMEOUT_WEBHOOK optional.

This temporarily marks the SLACK_GHA_TIMEOUT_WEBHOOK secret as optional until [63310] can be backported to older branches to avoid workflow failures.

Follow-up to [63310].

See #65845.

[johnbillion]

In 63315:

Build/Test Tools: Stop committing changes to tracked files in pull requests.

This workflow has not proven to be as useful as originally hoped, so it's being removed to reduce maintenance burden. All workflows that run the build script already fail if they result in untracked changes.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/13087

Props desrosj

See #65845

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

This adds a step to both the upgrade & installation test workflows to perform a checksum verification after downloading WordPress.

Trac ticket: Core-65845

## Use of AI Tools

None

Warning: File should not exist: wp-includes/php-ai-client/src/Providers/ApiBasedImplementation/AbstractApiBasedModelMetada
Warning: File should not exist: wp-includes/php-ai-client/src/Providers/ApiBasedImplementation/ListModelsApiBasedProviderA
Warning: File should not exist: wp-includes/php-ai-client/src/Providers/ApiBasedImplementation/GenerateTextApiBasedProvide
Warning: File should not exist: wp-includes/php-ai-client/src/Providers/ApiBasedImplementation/Contracts/ApiBasedModelInte
Warning: File should not exist: wp-includes/php-ai-client/src/Providers/OpenAiCompatibleImplementation/AbstractOpenAiCompa
Warning: File should not exist: wp-includes/php-ai-client/src/Providers/Models/ImageGeneration/Contracts/ImageGenerationMo
Warning: File should not exist: wp-includes/php-ai-client/src/Providers/Models/ImageGeneration/Contracts/ImageGenerationOp
Warning: File should not exist: wp-includes/php-ai-client/src/Providers/Models/SpeechGeneration/Contracts/SpeechGeneration
Warning: File should not exist: wp-includes/php-ai-client/src/Providers/Models/TextToSpeechConversion/Contracts/TextToSpee
Warning: File should not exist: wp-includes/php-ai-client/src/Providers/Models/TextGeneration/Contracts/TextGenerationOper
Warning: File should not exist: wp-includes/php-ai-client/src/Providers/Models/TextGeneration/Contracts/TextGenerationMode
Warning: File should not exist: wp-includes/php-ai-client/src/Providers/Models/VideoGeneration/Contracts/VideoGenerationOp
Warning: File should not exist: wp-includes/php-ai-client/src/Providers/Models/VideoGeneration/Contracts/VideoGenerationMo
Warning: File should not exist: wp-includes/php-ai-client/src/Providers/Contracts/ProviderWithOperationsHandlerInterface.p
Warning: File should not exist: wp-includes/php-ai-client/third-party/Http/Discovery/Exception/StrategyUnavailableExceptio
Warning: File should not exist: wp-includes/php-ai-client/third-party/Http/Discovery/Exception/PuliUnavailableException.ph
Warning: File should not exist: wp-includes/php-ai-client/third-party/Http/Discovery/Exception/NoCandidateFoundException.p
Warning: File should not exist: wp-includes/php-ai-client/third-party/Http/Discovery/Exception/ClassInstantiationFailedExc
Warning: File should not exist: wp-includes/php-ai-client/third-party/Http/Discovery/Exception/DiscoveryFailedException.ph
Warning: File should not exist: wp-includes/php-ai-client/third-party/Http/Discovery/Strategy/CommonPsr17ClassesStrategy.p

This error is strikingly similar to the problem reported with wp-cli. ​https://github.com/wp-cli/wp-cli/issues/6320

Consider using the nightly version of WP-CLI, or perhaps this issue will be resolved once a new version of WP-CLI is released. cc @swissspidy

Yep need to update to WP-CLI nightly. Though we're really working on the next stable release, hopefully right after 7.1 ships. So stay put.

btw shameless plug: ​https://github.com/swissspidy/wordpress-develop/pull/96

This applies the necessary changes to the GitHub Actions workflows for after the 7.1 final release.

Trac ticket: Core-65845.

## Use of AI Tools
None

[SergeyBiryukov]

In 63327:

Build/Test Tools: Test 7.1 in upgrade testing workflows.

This sets 7.1 as the most recent branch of WordPress in the upgrade testing workflows.

See #65845, #65844.

Nice, focused addition. Placing verification immediately after download isolates archive and extraction problems well.

One scalability question: this PR ran the checksum command 394 times, repeating the same WordPress/PHP check across database and multisite variants. Since extraction and checksum results should not depend on the database or multisite mode, could one representative job per WordPress/PHP pair provide the same signal with less WordPress.org API traffic and failure fan-out?

This is non-blocking; the current failures appear to be the known WP-CLI 2.12.0 extraction defect rather than a problem with this patch.

---
_{Adversarial review · <code>gpt-5.6-sol</code>}

While the REST API documents timed_out as a possible value for a job's conclusion, it turns out that value is never surfaced for a job object.

However, a cancellation and a time out can be determined by examining the annotations associated with a given job through the Checks API.

The one trade off of this approach is that checks: read must be added to all workflows that call this reusable one. Permissions are audited at the beginning of a run and it fails immediately when necessary permissions are lacking. So that would need to be backported to older branches right away.

If it's determined this is not worth the effort, then the original r63310 and r63313 commits should be reverted and the cancelled workflow notification can be adjusted to note that cancellations may also include time outs.

Trac ticket: Core-65845

## Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Used for: Full investigation, implementation, and live validation. Manually reviewed by myself and heavily modified the inline comments.

I've applied some changes to the conditional checks so that the new step runs and output data to confirm that everything is working as expected (​workflow run).

• The github.rest.actions.listJobsForWorkflowRunAttempt request ​returns an array of jobs.
• The annotation query to the GraphQL API ​returns an array of annotations.
• A time out is correctly identified.

[desrosj]

In 63396:

Build/Test Tools: Revert r63310 and r63313.

The changes in r63310 added logic to determine if a cancelled job was indeed cancelled and not a time out (which is also considered a cancellation). However, there are two issues with the code resulting in some blank notifications coming through to Slack.

First, the returned data is already processed and the jobs are returned as an array. This caused the step to throw an unhandled error and fail entirely for any run where a job was cancelled, regardless of whether it actually timed out.

Second, despite timed_out being documented as a possible value for the conclusion field, it appears that GitHub does not actually surface that conclusion in the context of a job. So this approach will not actually work and is being reverted until until an alternative presents itself.

Reverts r63310, r63313.

See #65845.

When changes to the reusable PHPUnit test workflows are made, the test old branches workflow runs to confirm that the changes do not break workflows within old branches. However, there are many workflows that make use of reusable workflow files, so the path filtering should be expanded.

Trac ticket: Core-65845.

## Use of AI Tools
None.

[lancewillett]

In 63415:

Build/Test Tools: Expand path filtering for the old branch testing workflow.

The test old branches workflow runs when the reusable PHPUnit test workflows change, to confirm those changes do not break workflows in old branches. Many other workflows also use reusable workflow files, so the path filtering is expanded to match.

Developed in: ​https://github.com/WordPress/wordpress-develop/pull/13089

Props desrosj.
See #65845.

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

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.

I would appreciate the proposed path changes being double checked in case I've missed something.

Ironically, changing these workflow files triggers the corresponding workflows in this PR.

I'm working on reviving this one for 7.2 release.

• Rebased onto trunk and force-pushed the existing branch
• Applied all filter fixes and changed the Trac reference to #65845 (https://core.trac.wordpress.org/ticket/65845)

@adimoldovan Could you please take a look at the approach?

This PR is ready for re-reviews.

Thanks @adimoldovan—the Sass gap is real. I verified that sass is in the build chain, sass:colors compiles src/wp-admin/css/colors/*/colors.scss, 157 .scss files are tracked, and reusable-test-core-build-process.yml runs npm run build. A Sass-only pull request therefore skips the build test today, so broken Sass could land. This is an existing gap, not one introduced by this PR.

I also agree with the failure-mode argument for exclusions. A missing include silently loses coverage. A missing exclude causes one unnecessary run, which is visible.

Before changing the PR’s shape, I want to replay the proposed exclusion lists against the same 12 months of trunk history—1,800 commits—used to measure the current version. The include lists avoided roughly 790 runs per year. If exclusions save about the same amount, they win on safety without a meaningful efficiency trade-off.

GitHub’s documentation confirms that ordered negative and positive patterns work for both push and pull_request. It defines ** as matching all file paths, but does not separately document dot-prefixed paths. That ambiguity should not block the approach: we can keep the explicit !.github/** exclusion, re-include the relevant workflow files afterward, and cover those cases in the replay and targeted validation.

#65845 is milestoned for 7.2, and I’m focused on the 7.1.1 RC through September 10th. I expect to have the replay results the following week. I’ll also make sure Sass-only changes trigger the build test in the final version.

_Transparency in AI usage: I used Claude Code Opus 5 to verify the Sass claim against the Gruntfile and workflow files._

Thanks @adimoldovan—the Sass gap is real. I verified that sass is in the build chain, sass:colors compiles src/wp-admin/css/colors/*/colors.scss, 157 .scss files are tracked, and reusable-test-core-build-process.yml runs npm run build. A Sass-only pull request therefore skips the build test today, so broken Sass could land. This is an existing gap, not one introduced by this PR.

I also agree with the failure-mode argument for exclusions. A missing include silently loses coverage. A missing exclude causes one unnecessary run, which is visible.

Before changing the PR’s shape, I want to replay the proposed exclusion lists against the same 12 months of trunk history—1,800 commits—used to measure the current version. The include lists avoided roughly 790 runs per year. If exclusions save about the same amount, they win on safety without a meaningful efficiency trade-off.

GitHub’s documentation confirms that ordered negative and positive patterns work for both push and pull_request. It defines ** as matching all file paths, but does not separately document dot-prefixed paths. That ambiguity should not block the approach: we can keep the explicit !.github/** exclusion, re-include the relevant workflow files afterward, and cover those cases in the replay and targeted validation.

_Transparency in AI usage: I used Claude Code Opus 5 to verify the Sass claim against the Gruntfile and workflow files._

Thanks @adimoldovan—the Sass gap is real. I verified that sass is in the build chain, sass:colors compiles src/wp-admin/css/colors/*/colors.scss, 157 .scss files are tracked, and reusable-test-core-build-process.yml runs npm run build. A Sass-only pull request therefore skips the build test today, so broken Sass could land. This is an existing gap, not one introduced by this PR.

I also agree with the failure-mode argument for exclusions. A missing include silently loses coverage. A missing exclude causes one unnecessary run, which is visible.

Before changing the PR’s shape, I want to replay the proposed exclusion lists against the same 12 months of trunk history—1,800 commits—used to measure the current version. The include lists avoided roughly 790 runs per year. If exclusions save about the same amount, they win on safety without a meaningful efficiency trade-off.

GitHub’s documentation confirms that ordered negative and positive patterns work for both push and pull_request. It defines ** as matching all file paths, but does not separately document dot-prefixed paths. That ambiguity should not block the approach: we can keep the explicit !.github/** exclusion, re-include the relevant workflow files afterward, and cover those cases in the replay and targeted validation.

_Transparency in AI usage: I used Claude Code Opus 5 to verify the Sass claim against the Gruntfile and workflow files._

@adimoldovan I switched the seven broad filters to exclusion-first in 70b7fc166c.

I replayed both versions across the same 1,789 trunk commits from July 25th, 2025 through July 25th, 2026:

• Current include version: 665 avoided workflow runs.
• Exclusion version: 631 avoided workflow runs.
• Difference: 34 additional runs for the exclusion version—fewer than three per month.
• Coverage: no commit or currently tracked path covered by the include version was missed by the exclusion version.

The earlier estimate of roughly 790 avoided runs came from an earlier PR revision. The coverage fixes added since then reduced the current comparison baseline to 665.

The 34 extra runs are the intended safety margin. They cover changes such as Sass, certificates, fonts, and environment files. A Sass-only change now triggers the build test, and a new source file type runs the seven converted workflows by default.

I also verified the workflow files with actionlint and targeted path fixtures, including dot-prefixed workflow paths and positive patterns after exclusions.

---
_{Adversarial review · <code>gpt-5</code>}

I updated the original PR body to make this change easier to understand and review.

@adimoldovan I'd love another review please

Thanks @adimoldovan—I addressed all inline feedback in 98f1166264 and refreshed the branch from trunk. The replay now shows that the exclusion filters retain 629 of 671 avoided runs while adding 42 safety runs; they miss no paths covered by the proposed include filters. actionlint and targeted path checks pass. CI is running—could you re-review when ready?

[lancewillett]

In 63519:

Build/Test Tools: Use exclusion-first workflow path filters.

Replace narrow include lists in GitHub Actions workflows with ordered exclusion filters. New source paths now run by default, while known unrelated paths continue to skip unnecessary jobs.

Preserve each workflow's build and test dependencies, including Sass, JSHint, webpack, vendor tools, and reusable workflow files. Also include wp-cli.yml in local Docker testing and repository-root PHP files in upgrade testing.

Developed in: ​https://github.com/WordPress/wordpress-develop/pull/9457

Props johnbillion, peterwilsoncc, desrosj, adrianmoldovanwp.
See #65845.

Landed in https://core.trac.wordpress.org/changeset/63519

[desrosj]

In 63557:

Build/Test Tools: Increase PHPUnit workflow timeout-minutes.

There has been a considerable number of PHPUnit test workflow runs recently that have been hitting the default configured timeout-minutes value of 20.

This increases the value to 30 to avoid runs being cancelled prematurely until the speed of the test suite can be improved.

See #65845.

[desrosj]

In 63558:

Build/Test Tools: Increase Gutenberg artifact retention.

It’s common for nuanced workflow run failures to be investigated over the course of several days following the initial run. In these cases, the entire workflow must be rerun even one only one or two jobs had failed because the artifact has expired.

This increases the artifact retention of the built Gutenberg asset from 1 day to 7 to help with this workflow.

See #65845.