Repository navigation
Github PHP changes workflow: remove it - #62609
Merged
Merged
Conversation
Member
|
Looks good to me unless anyone in @WordPress/gutenberg-core has any objections 👍 |
|
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. |
tellthemachines
approved these changes
Jun 17, 2024
tellthemachines
left a comment
tellthemachines
left a comment
Contributor
There was a problem hiding this comment.
This makes sense, thanks for the cleanup!
Member
|
No objections, if you think the failing test is enough. I was wondering if the backport log test should leave an actual Github comment instead, though there should be a clear error message if you open the test results. |
…k backport changelog workflow is in place.
ramonjd
force-pushed
the
remove/php-detection-workflow
branch
from
June 17, 2024 07:52
a84af57 to
c5bd1de
Compare
ramonjd
enabled auto-merge (squash)
June 17, 2024 07:52
|
Flaky tests detected in c5bd1de. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/9543945900
|
huubl
pushed a commit
to huubl/gutenberg
that referenced
this pull request
Jun 17, 2024
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org> Co-authored-by: tellthemachines <isabel_brison@git.wordpress.org> Co-authored-by: noisysocks <noisysocks@git.wordpress.org> Co-authored-by: ellatrix <ellatrix@git.wordpress.org>
desrosj
added a commit
that referenced
this pull request
Sep 21, 2026
`php-changes-detection.yml` runs on every pull request opened against this branch (`pull_request: types: [opened, synchronize]`, with no branch filter) and, whenever the PR touches `lib/`, `phpunit/` or any `packages/**/*.php` file, posts and then keeps updating a bot comment asking the author to confirm whether the change needs to be synced to WordPress Core "and therefore featured in the next release of WordPress", recommending a new Trac ticket and a matching pull request against `WordPress/wordpress-develop`. That prompt only makes sense for work landing on `trunk`. `wp/6.6` mirrors the Gutenberg code already shipped in WordPress 6.6; PHP changes made here are maintenance for an already-released version, coordinated through the backport process for that specific release rather than discovered by a bot comment. The workflow's only effect on this branch is a comment giving the wrong instructions. Upstream reached the same conclusion for `trunk` and deleted the workflow outright in #62609 (2024-06-17). `wp/6.6` branched from `trunk` on 2024-05-31, a couple of weeks before that removal landed, which is the only reason the file is still here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DtSAAJkQ9P6vPtDumqStg8
desrosj
added a commit
that referenced
this pull request
Sep 21, 2026
`php-changes-detection.yml` has no branch or path filter, so it runs on every single pull request opened against this branch. When a pull request touches PHP, it posts (and keeps updating) a bot comment asking the author to confirm whether the change needs syncing to WordPress Core, to open a Trac ticket, and to send a matching `wordpress-develop` pull request so the change is "featured in the next release of WordPress". That prompt is wrong on `wp/6.5`. This branch exists to hold the Gutenberg code that shipped with WordPress 6.5, released in April 2024; work landing here is not a candidate for the next WordPress release, and the Core sync it points contributors toward happens from `trunk`. The comment is inaccurate guidance, and on the remaining pull requests it is a job that runs on every push to produce nothing. `trunk` removed this workflow outright in #62609 for the same reason — noise, superseded by the backport-changelog workflow, which postdates this branch and does not exist here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DtSAAJkQ9P6vPtDumqStg8
This was referenced Sep 21, 2026
desrosj
added a commit
that referenced
this pull request
Sep 22, 2026
`php-changes-detection.yml` runs on every pull request opened against this branch (`pull_request: types: [opened, synchronize]`, with no branch filter) and, whenever the PR touches `lib/`, `phpunit/` or any `packages/**/*.php` file, posts and then keeps updating a bot comment asking the author to confirm whether the change needs to be synced to WordPress Core "and therefore featured in the next release of WordPress", recommending a new Trac ticket and a matching pull request against `WordPress/wordpress-develop`. That prompt only makes sense for work landing on `trunk`. `wp/6.6` mirrors the Gutenberg code already shipped in WordPress 6.6; PHP changes made here are maintenance for an already-released version, coordinated through the backport process for that specific release rather than discovered by a bot comment. The workflow's only effect on this branch is a comment giving the wrong instructions. Upstream reached the same conclusion for `trunk` and deleted the workflow outright in #62609 (2024-06-17). `wp/6.6` branched from `trunk` on 2024-05-31, a couple of weeks before that removal landed, which is the only reason the file is still here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DtSAAJkQ9P6vPtDumqStg8
desrosj
added a commit
that referenced
this pull request
Sep 22, 2026
`php-changes-detection.yml` has no branch or path filter, so it runs on every single pull request opened against this branch. When a pull request touches PHP, it posts (and keeps updating) a bot comment asking the author to confirm whether the change needs syncing to WordPress Core, to open a Trac ticket, and to send a matching `wordpress-develop` pull request so the change is "featured in the next release of WordPress". That prompt is wrong on `wp/6.5`. This branch exists to hold the Gutenberg code that shipped with WordPress 6.5, released in April 2024; work landing here is not a candidate for the next WordPress release, and the Core sync it points contributors toward happens from `trunk`. The comment is inaccurate guidance, and on the remaining pull requests it is a job that runs on every push to produce nothing. `trunk` removed this workflow outright in #62609 for the same reason — noise, superseded by the backport-changelog workflow, which postdates this branch and does not exist here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DtSAAJkQ9P6vPtDumqStg8
desrosj
added a commit
that referenced
this pull request
Sep 22, 2026
`php-changes-detection.yml` runs on every pull request opened against this branch (`pull_request: types: [opened, synchronize]`, with no branch filter) and, whenever the PR touches `lib/`, `phpunit/` or any `packages/**/*.php` file, posts and then keeps updating a bot comment asking the author to confirm whether the change needs to be synced to WordPress Core "and therefore featured in the next release of WordPress", recommending a new Trac ticket and a matching pull request against `WordPress/wordpress-develop`. That prompt only makes sense for work landing on `trunk`. `wp/6.6` mirrors the Gutenberg code already shipped in WordPress 6.6; PHP changes made here are maintenance for an already-released version, coordinated through the backport process for that specific release rather than discovered by a bot comment. The workflow's only effect on this branch is a comment giving the wrong instructions. Upstream reached the same conclusion for `trunk` and deleted the workflow outright in #62609 (2024-06-17). `wp/6.6` branched from `trunk` on 2024-05-31, a couple of weeks before that removal landed, which is the only reason the file is still here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DtSAAJkQ9P6vPtDumqStg8
desrosj
added a commit
that referenced
this pull request
Sep 22, 2026
`php-changes-detection.yml` has no branch or path filter, so it runs on every single pull request opened against this branch. When a pull request touches PHP, it posts (and keeps updating) a bot comment asking the author to confirm whether the change needs syncing to WordPress Core, to open a Trac ticket, and to send a matching `wordpress-develop` pull request so the change is "featured in the next release of WordPress". That prompt is wrong on `wp/6.5`. This branch exists to hold the Gutenberg code that shipped with WordPress 6.5, released in April 2024; work landing here is not a candidate for the next WordPress release, and the Core sync it points contributors toward happens from `trunk`. The comment is inaccurate guidance, and on the remaining pull requests it is a job that runs on every push to produce nothing. `trunk` removed this workflow outright in #62609 for the same reason — noise, superseded by the backport-changelog workflow, which postdates this branch and does not exist here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DtSAAJkQ9P6vPtDumqStg8
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Removing the PHP changes workflow
Why?
The PHP detections action checks for PHP changes and adds a comment to ask whether a backport is necessary.
Example:
I think it's just noise now that the check backport changelog workflow is in place.
Also to reduce clutter.