[desrosj]

Part of #82928.

What?

This removes several GitHub Actions workflows from the wp/6.5 branch.

Workflow	Purpose	Reason removed	Trunk removal PR
rnmobile-ios-runner.yml	React Native iOS E2E test runner	Job runs on macos-12, a runner image GitHub fully retired in December 2024; it now fails to even schedule a runner	#76503
rnmobile-android-runner.yml	React Native Android E2E test runner	Job runs on macos-12, a runner image GitHub fully retired in December 2024; it now fails to even schedule a runner	#76503
gradle-wrapper-validation.yml	Validates the Gradle wrapper checksum used by the React Native Android build	Orphaned once the Android E2E workflow it supported became unusable	#79030
storybook-pages.yml	Deploys the canonical Storybook GitHub Pages site	push: branches: [trunk] only — a single deploy target, not per-branch	N/A — still active on trunk
upload-release-to-plugin-repo.yml	Uploads the built plugin zip to the WordPress.org SVN repo on release publish	Plugin releases are cut from trunk/release branches, never from wp/X.Y branches	N/A — still active on trunk
stale-issue-gardening.yml	Daily scheduled bot that marks/closes stale issues and PRs	schedule-triggered workflows only ever run using the default branch's copy	N/A — still active on trunk
check-components-changelog.yml	Fails a PR touching packages/components/** unless it adds a ## Unreleased entry to packages/components/CHANGELOG.md linking to that PR	This branch's packages/components/CHANGELOG.md is frozen at 26.0.2 (2024-04-09) and mirrors the package history that shipped with WordPress 6.5. Backports landing here already have their CHANGELOG entry on trunk under the original PR number, so satisfying this check would mean adding a second, branch-local entry pointing at the backport — divergence from the released history rather than documentation of it	#78169 (consolidated into check-package-changelogs.yml)
php-changes-detection.yml	Runs on every PR (no branch or path filter) and comments on any PR touching PHP, asking the author to sync the change to WordPress Core via a Trac ticket and a wordpress-develop PR so it lands in "the next release of WordPress"	Inaccurate guidance on a frozen branch: wp/6.5 holds the code that shipped with WordPress 6.5 (April 2024), work landing here is not a candidate for the next WordPress release, and the Core sync it points to happens from trunk. On every other PR it is a job that runs on each push and produces nothing	#62609
performance.yml	Performance tests	Performance testing is only maintained on the branch for the current WordPress release	N/A — still active on trunk
pull-request-automation.yml	Assigns fixed issues and labels first-time contributors on new pull requests	pull_request_target runs always use trunk's copy of the file, and its push-triggered tasks return immediately outside trunk, so this branch's copy never does anything	N/A — still active on trunk
enforce-pr-labels.yml	Requires exactly one [Type] label on each pull request	pull_request_target only, and those runs always use trunk's copy of the file, so this branch's copy never runs	N/A — still active on trunk
build-plugin-zip.yml	Builds the plugin zip, and holds the plugin release jobs (version bump, GitHub release, npm latest publish)	Nothing uses the zip it builds: WordPress 6.5 takes Gutenberg as npm packages. The release jobs only run when started from trunk or a release/* branch, so they never run from wp/X.Y	N/A — still active on trunk

Why?

These workflows are not relevant to the branch, mostly due to the fact that they only run from trunk, are permanently disabled or non-functional, are not meant for running with non-latest code, or are only maintained for the current WordPress release (performance testing). Removing them also cuts down on the long-term maintenance burden, and avoids causing confusion.

Use of AI Tools

This PR was created by Claude Code under my supervision. All code should be treated as AI-produced and not yet reviewed by a human until this PR is marked Ready for Review.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: 79ea97bc-a420-4f09-9fae-1b7a65981364

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs.

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: desrosj <desrosj@git.wordpress.org>
Co-authored-by: lucatume <lucatume@git.wordpress.org>

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

---

Props Bot commands

You can trigger Props Bot actions by commenting on this PR:

• @propsbot add <username> to give props to a GitHub user. Requires write access.
• @propsbot remove <username> to leave a user out of the props. Requires write access.
• @propsbot refresh to refresh this list. Adding the props-bot label works too.