Repository navigation
Conversation
`rnmobile-ios-runner.yml` and `rnmobile-android-runner.yml` both hardcode `if: false` on their only job and have not run on any push or pull request since before this branch existed. `gradle-wrapper-validation.yml` exists solely to validate the Gradle wrapper used by that same disabled Android tooling, and is equally unused as a result.
2475307 to
9a456c8
Compare
|
Flaky tests detected in 8a295c3. 🔍 Workflow run URL: https://github.com/desrosj/gutenberg/actions/runs/34549462844 should undo typing after non input change in
|
9a456c8 to
d2a3fb8
Compare
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
d2a3fb8 to
d88d164
Compare
`storybook-pages.yml` deploys the single canonical Storybook GitHub Pages site and only triggers on pushes to `trunk`; there is one Storybook site for the whole project, not one per branch, so this branch's copy can never run. `storybook-check.yml` is kept, not removed here — per updated project policy, it is restored to this branch wherever a prior pass removed it.
`check-components-changelog.yml`, `check-backport-changelog.yml`, and `check-dataviews-changelog.yml` all trigger on `pull_request: branches: [trunk]`, so none of them can run against a pull request targeting this branch.
`upload-release-to-plugin-repo.yml` triggers on GitHub release publication; Gutenberg plugin releases are cut from `trunk` and release branches, never from `wp/X.Y` branches. `sync-assets-to-plugin-repo.yml` triggers only on pushes to `trunk` that touch `assets/**`.
`cherry-pick-wp-release.yml` only triggers on pushes to `trunk` or labeled pull requests targeting `trunk`. `wp/X.Y` branches, including this one, are the destination its `git push` step writes to, never its trigger source. `publish-npm-packages.yml` is kept on this branch per updated project policy, even though it is only reachable via `workflow_dispatch`.
`sync-backport-changelog.yml` triggers only on pushes to `trunk` (plus an issue-label event unrelated to any branch). `stale-issue-gardening.yml` is schedule-triggered, and GitHub only ever runs a scheduled workflow using the copy on the repository's default branch, regardless of any copy present elsewhere.
Every step in `pull-request-automation.yml` explicitly checks out `ref: trunk` regardless of which branch or event actually triggered the workflow. On a `wp/X.Y` branch, that means the workflow only ever executes trunk's own copy of the automation, never this branch's copy. Keeping a copy of the workflow file here is pointless even though the trigger itself is real and does fire on this branch.
8a295c3 to
9ca40a9
Compare
|
Migrated to real upstream: WordPress#82797. Closing this fork PR. |
What?
Removes obsolete React Native mobile workflows and every workflow whose triggers make it trunk-only, from
wp/7.0.rnmobile-ios-runner.ymlif: false; has not run since before this branch existedrnmobile-android-runner.ymlif: false; has not run since before this branch existedgradle-wrapper-validation.ymlstorybook-pages.ymlpush: branches: [trunk]onlycheck-backport-changelog.ymlpull_request: branches: [trunk]onlycheck-components-changelog.yml@wordpress/componentschangelog entrypull_request: branches: [trunk]onlycheck-dataviews-changelog.yml@wordpress/dataviewschangelog entrypull_request: branches: [trunk]onlyupload-release-to-plugin-repo.ymltrunk/release branches, neverwp/X.Ysync-assets-to-plugin-repo.ymlassets/**to the WordPress.org plugin repopush: branches: [trunk]onlycherry-pick-wp-release.ymlwp/X.Ybranchestrunk; this branch is its destination, never its trigger sourcesync-backport-changelog.ymlpush: branches: [trunk], plus anissues: labeledtrigger that isn't tied to any git ref — like the schedule case below, GitHub always runs it from the default branch's copy regardless of what's on this branchstale-issue-gardening.ymlpull-request-automation.ymlref: trunkregardless of which branch or event actually triggered the workflow, so onwp/X.Yit only ever executes trunk's own copy of the automation. The trigger itself is real and does fire on this branch — but keeping a copy of the workflow file here is pointless, since it can never run anything but trunk's logicWhy?
Keeping dead or inapplicable workflow files around adds maintenance surface (stale action pins, lint noise) with no corresponding benefit.
The workflows removed cannot be meaningfully executed against a branch other than
trunk.scheduleevents, the event only ever fires for the default branch.trunk(except minor releases, which come from the respectiverelease/X.Ybranch).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.