Workflows: Refine and complete the push and pull_request branch filters by desrosj · Pull Request #82744 · WordPress/gutenberg

desrosj · 2026-09-10T18:54:24Z

What?

This makes adjustments to the push and pull_request branch filters across the GitHub Actions workflows.

release/** and wp/** become more explicit using release/[0-9]+.[0-9] and wp/[0-9]+.[0-9].
Explicit entries for the long-lived wp/latest and wp/next branches were added.
Several workflows that declared push or pull_request with no branch filter at all now carry one.

Why?

Since the ** matches any character (including /), a branch named wp/wp-7.0/something-else would match but the intention is for the workflow to only run for wp/X.Y and release/X.Y branches. This avoids running workflows unnecessarily for irrelevant branches.

Separately, a workflow that declares an event with no branches: key runs for every branch or every base branch. pull-request-automation was the clearest case. The bare push: triggered a checkout, a Node install and a build on every push to every branch in the repository, and both of its push-driven tasks then returned early because they check for trunk themselves.

How?

The filter set used by the branch-sensitive workflows is:

branches:
    - trunk
    - 'release/[0-9]+.[0-9]'
    - 'wp/[0-9]+.[0-9]'
    - wp/latest
    - wp/next

Per workflow

Workflow	Change
`build-plugin-zip`, `end2end-test`, `static-checks`, `unit-test`	`push` narrowed from `release/` and `wp/` to the explicit patterns above
`create-block`	`push` widens from `trunk` and `wp/latest` to that set
`workflow-lint`	`push` widens from `trunk` to that set, so workflow files on a release or `wp/*` branch are linted too. The `trunk` filter on `pull_request` is dropped, so a pull request targeting one of those branches is linted as well. Both events keep their `paths` filter
`pull-request-automation`	The bare `push:` gains `trunk`, and only `trunk`
`storybook-check`	`pull_request` gains `trunk`, matching its `push` filter, since Storybook only publishes from `trunk`

pull-request-automation is the one workflow held to trunk alone, because the action decides for itself that nothing else matters. Its automation table binds two tasks to push, add-milestone and first-time-contributor-account-link, and each one opens by comparing the pushed ref against refs/heads/trunk and returning early otherwise. Their test suites cover that early return. The two remaining tasks are bound to pull_request_target, which this change does not touch, and neither downstream job reads the pushed ref: welcome is gated on an output only the pull_request_target task sets, and account-link on one that only a push to trunk produces. A branches filter also keeps the workflow off tag pushes, which a bare push: matches as well, so release tags no longer start a run that does nothing.

Everywhere else pull_request stays unfiltered on purpose. A pull request should get the same checks whatever branch it targets, and bundle-size is the clearest example: it is not tied to trunk at all, because preactjs/compressed-size-action takes the base ref and base SHA from the pull request payload and builds whichever branch the pull request is based on. storybook-check is the deliberate exception, since there is no Storybook published from anywhere but trunk to check against.

The rest of the workflows are already correctly scoped and are left alone. check-backport-changelog, check-package-changelogs, required-changes-from-trunk, cherry-pick-wp-release, sync-assets-to-plugin-repo, sync-backport-changelog and storybook-pages are tied to trunk, and performance already limits push to trunk. enforce-pr-labels, pr-labeling-automation, props-bot and notify-slack-on-label are labeling and metadata automation that should fire for every pull request regardless of base.

Use of AI Tools

Authored with Claude Code. Every edit was reviewed and directed by me, including which workflows to change and which to leave alone. The narrowing of release/** and wp/**, the decision to list wp/latest and wp/next explicitly, and the per-workflow filter choices were mine; Claude produced the report those decisions were made from, applied the edits and verified that each workflow file still parses.

Until this PR is marked ready for review, please consider the code unreviewed.

Generated by Claude Code

The `release/**` and `wp/**` globs match any ref under those prefixes, including nested ones such as `release/2.5/something-else` and one-off working branches like `release/23.2-cherry-pick` or `wp/6.7_meta-boxes-unsplit-with-device-previews`. Replace them with `release/[0-9]+.[0-9]` and `wp/[0-9]+.[0-9]`, which match a major version of any length followed by a single-digit minor version, and nothing else. `+` and `[]` are both supported by the GitHub Actions filter pattern syntax. `wp/latest` and `wp/next` are long-lived branches that the old `wp/**` glob covered, and the package release process depends on the build for `wp/latest` passing. List both explicitly so they keep their coverage. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01T6xDpCEksxnHD9LvcfRZdx

Several workflows declared `push` or `pull_request` with no branch filter at all, so they ran for every base branch in the repository. Give each the filter its job actually calls for. - `build-plugin-zip`, `end2end-test`, `static-checks` and `unit-test` gain a `pull_request` filter matching their `push` filter, so the suites that guard a branch also guard the pull requests targeting it. - `performance` and `create-block` move to that same set on both events. - `workflow-lint` widens from `trunk` to that same set on both events: the workflow files on a release or `wp/*` branch need linting too. - `bundle-size` gains the same set on `pull_request`. The comparison builds whatever the pull request is based on, taking the base from the event payload, so it is not tied to `trunk`. - `storybook-check` narrows to `trunk` on `pull_request`, matching its `push` filter. Storybook is only published from `trunk`. `performance` published its push results under a hardcoded `trunk` series name. Now that pushes to the release and `wp/*` branches run it too, pass the branch the run is for instead, so their measurements no longer land in the `trunk` history. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01T6xDpCEksxnHD9LvcfRZdx

The `push` key carried no branch filter, so every push to every branch in the repository checked the repository out, installed Node and ran a build. Scope it to the same branches the other workflows now use. Both push-driven tasks still return early unless the ref is `trunk`, which they check themselves in `add-milestone` and `first-time-contributor-account-link`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01T6xDpCEksxnHD9LvcfRZdx

github-actions · 2026-09-10T18:54:40Z

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.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @claude.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

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

Unlinked contributors: claude.

Co-authored-by: desrosj <desrosj@git.wordpress.org>
Co-authored-by: tyxla <tyxla@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>

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

github-actions · 2026-09-10T18:54:40Z

🤖 PR meta 🤖

📦 Bundle size

Size Change: 0 B

Total Size: 8.06 MB

_{From 3fea68f, not the current head. Run}

🏁 Flaky tests

Show the failures

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.

Navigates the items list via UP/DOWN arrow keys in /test/e2e/specs/site-editor/dataviews-list-layout-keyboard.spec.js, passed after 1 failed attempt.

Error: expect(locator).toBeFocused() failed

Locator:  getByLabel('Page Two')
Expected: focused
Received: inactive
Timeout:  5000ms

Call log:
  - Expect "toBeFocused" getByLabel('Page Two') with timeout 5000ms
  - waiting for getByLabel('Page Two')
    14 × locator resolved to <button type="button" tabindex="-1" aria-pressed="false" id="view-list-0-310-item-wrapper" class="dataviews-view-list__item" aria-labelledby="view-list-0-310-label" aria-describedby="view-list-0-310-description"></button>
       - unexpected value "inactive"

    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/site-editor/dataviews-list-layout-keyboard.spec.js:146:49

applies the filtered form to the Quick Edit DataForm @site-editor-v1-only in /test/e2e/specs/site-editor/view-config-extensibility.spec.js, passed after 1 failed attempt.

Error: apiRequestContext.fetch: socket hang up
Call log:
  - → PUT http://localhost:8889/wp-json/wp/v2/plugins/gutenberg-test-plugins/view-config-extensibility
    - user-agent: Playwright/1.63.0 (x64; ubuntu 24.04) node/24.18 CI/1
    - accept: */*
    - accept-encoding: gzip,deflate,br
    - X-WP-Nonce: 3da047a697
    - content-type: application/json
    - content-length: 21
    - cookie: wordpress_test_cookie=WP%20Cookie%20check; wordpress_logged_in_23778236db82f19306f247e20a353a99=admin%7C1789575962%7Cav81C5P4ZOFgsoo9mt1hQHALzpyWQ5XvAAM8H53FclZ%7Cb3da469490a87cf14d8eba74154d4143caf3e0d976444a438d1ad60cc55938f1; wp-settings-time-1=1789403784

    at RequestUtils.rest (/home/runner/work/gutenberg/gutenberg/packages/e2e-test-utils-playwright/src/request-utils/rest.ts:112:39)
    at RequestUtils.deactivatePlugin (/home/runner/work/gutenberg/gutenberg/packages/e2e-test-utils-playwright/src/request-utils/plugins.ts:89:13)
    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/site-editor/view-config-extensibility.spec.js:57:3

_{5b532de Run}

Copilot

🟡 Changes recommended

Pull-request automation still performs expensive no-op runs on non-trunk release and WP pushes.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Refines GitHub Actions branch filters to target maintained branches and correctly separates performance results by branch.

Changes:

Narrows release and WordPress branch patterns.
Aligns push and pull-request filters.
Uses the pushed branch for performance reporting.

File summaries

File	Description
`.github/workflows/workflow-lint.yml`	Expands filtered branches.
`.github/workflows/unit-test.yml`	Aligns push and PR filters.
`.github/workflows/storybook-check.yml`	Limits PR checks to trunk.
`.github/workflows/static-checks.yml`	Aligns push and PR filters.
`.github/workflows/pull-request-automation.yml`	Adds a push branch filter.
`.github/workflows/performance.yml`	Expands filters and separates branch results.
`.github/workflows/end2end-test.yml`	Aligns push and PR filters.
`.github/workflows/create-block.yml`	Expands filtered branches.
`.github/workflows/bundle-size.yml`	Adds PR branch filtering.
`.github/workflows/build-plugin-zip.yml`	Narrows release branch filters.

Review details

Files reviewed: 10/10 changed files
Comments generated: 1
Review effort level: Balanced

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Removes the local `reusable-workflow-lint.yml` and points `workflow-lint.yml` at `WordPress/gutenberg/.github/workflows/reusable-workflow-lint.yml@trunk` instead, so this branch always lints against trunk's current lint logic rather than a stale local copy. Also widens `workflow-lint.yml`'s own `push`/`pull_request` branch filters from `trunk` only to also include `release/[0-9]+.[0-9]`, `wp/[0-9]+.[0-9]`, `wp/latest`, and `wp/next` — porting `WordPress#82744`'s fix for this file. Without this, pushes or pull requests targeting this branch itself never triggered linting at all, since `trunk` was the only branch the filter recognized.

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

Removes the local `reusable-workflow-lint.yml` and points `workflow-lint.yml` at `WordPress/gutenberg/.github/workflows/reusable-workflow-lint.yml@trunk` instead, so this branch always lints against trunk's current lint logic rather than a stale local copy. Also widens `workflow-lint.yml`'s own `push`/`pull_request` branch filters from `trunk` only to also include `release/[0-9]+.[0-9]`, `wp/[0-9]+.[0-9]`, `wp/latest`, and `wp/next` — porting `WordPress#82744`'s fix for this file. Without this, pushes or pull requests targeting this branch itself never triggered linting at all, since `trunk` was the only branch the filter recognized.

Copilot

🟡 Changes recommended

Performance and pull-request automation filters omit the maintained release and WordPress branches.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Files reviewed: 10/10 changed files
Comments generated: 2
Review effort level: Lite

Ports upstream trunk PR WordPress#82744 (head commit 3fe3bd4 as of this writing; the PR is still open/unmerged), "Workflows: Refine and complete the push and pull_request branch filters": - Narrows/widens `push:` branch filters on unit-test/end2end-test/static-checks/ build-plugin-zip/create-block/workflow-lint (where present) to the precise upstream set (trunk, release/X.Y, wp/X.Y, wp/latest, wp/next), fixing workflows that previously never ran on a direct push to this branch. Per the current version of that upstream PR, `pull_request:` triggers are deliberately left unfiltered everywhere (a PR should get the same checks regardless of which branch it targets) — the one exception upstream carves out is `workflow-lint.yml`, where a previous trunk-only `pull_request` filter is removed entirely rather than widened. This supersedes this project's earlier port of an older revision of WordPress#82744, which had added an explicit `pull_request` branch allowlist (plus a project-local temporary `fix-actions-[0-9]+.[0-9]/**` pattern) to several files. That's been reverted here to match the upstream author's updated approach — since `pull_request` now stays unfiltered, the temporary project-local pattern is no longer needed at all.

Removes the local `reusable-workflow-lint.yml` and points `workflow-lint.yml` at `WordPress/gutenberg/.github/workflows/reusable-workflow-lint.yml@trunk` instead, so this branch always lints against trunk's current lint logic rather than a stale local copy. Also widens `workflow-lint.yml`'s own `push`/`pull_request` branch filters from `trunk` only to also include `release/[0-9]+.[0-9]`, `wp/[0-9]+.[0-9]`, `wp/latest`, and `wp/next` — porting `WordPress#82744`'s fix for this file. Without this, pushes or pull requests targeting this branch itself never triggered linting at all, since `trunk` was the only branch the filter recognized.

Ports upstream trunk PR WordPress#82744 (head commit 3fe3bd4 as of this writing; the PR is still open/unmerged), "Workflows: Refine and complete the push and pull_request branch filters": - Narrows/widens `push:` branch filters on unit-test/end2end-test/static-checks/ build-plugin-zip/create-block/workflow-lint to the precise upstream set (trunk, release/X.Y, wp/X.Y, wp/latest, wp/next), fixing workflows that previously never ran on a direct push to this branch. - workflow-lint.yml's pull_request branch filter is removed entirely (previously the full upstream set plus a project-local pattern), since pull_request checks should run for a PR targeting any branch. Per the current version of that upstream PR, `pull_request:` triggers are deliberately left unfiltered everywhere (a PR should get the same checks regardless of which branch it targets) — the one exception upstream carves out is `workflow-lint.yml`, where a previous trunk-only `pull_request` filter is removed entirely rather than widened. This supersedes this project's earlier port of an older revision of WordPress#82744, which had added an explicit `pull_request` branch allowlist (plus a project-local temporary `fix-actions-[0-9]+.[0-9]/**` pattern) to several files. That's been reverted here to match the upstream author's updated approach — since `pull_request` now stays unfiltered, the temporary project-local pattern is no longer needed at all.