Workflows: try a backport changelog

[ellatrix]

What?

This PR introduces a test that checks if an entry with a core backport PR has been added to the backport changelog.

Entries are added as files to prevent merge/rebase conflicts. The expectation would be one file per core backport PR, which can contain a list of multiple Gutenberg PRs.

The files can be sorted per release: 6.6 changes go in the 6.6 folder.

Why?

The goal of this PR is to make sure that core backport PRs are created before a PR that requires a backport is merged into GB. This encourages PR authors to think about how it will be absorbed into core early, increases visibility, and allows us to merge the core PRs as soon as possible, which prevents a "queue" of many PRs to be backported (that may depend on one another).

The PR author will have to create a backport at some point anyway. I think it's more productive to do it sooner while it’s fresh and while you’re looking at the core files that you’re filtering/overriding.

If there's an existing (and open) core backport PR that a change is related to, it's ok to use that existing core PR. So if you wish to make multiple successive PHP changes, it's fine to start a backport PR and use that for all these related PRs. This makes it easier for others to know which PRs belong together (normally when a backport issue is created, it's really hard to figure out which PRs belong together and can go into the same backport PR).

Also note that you don't need to open a backport PR as soon as you create a GB PR, it should just be done before merging to trunk. Maybe we can skip running this test for draft PRs.

Probably we'll go through some time where we have remaining backports (#61226) and it's not possible to create a backport PR without previous changes. We are now two weeks from Beta 1, so we should prioritise getting those remaining backports merged as soon as possible.

If this works well, I can see it replace the backport issue entirely, or it becomes just of formality where we double check all the changes, but almost no work is needed.

How?

This script is inspired by the components changelog: we check a special changelog whenever a PHP change is made.

Testing Instructions

• I'm first running this PR without any PHP changes, to make sure that the test does not run.
• Then I'll make a PHP change to make sure the test fails. (skip confirmed)
• I'll then add an entry to changelog until it passes. (works: https://github.com/WordPress/gutenberg/actions/runs/9154811094/job/25166026310)
• Finally I'll remove the PHP change and changelog entry again.

Testing Instructions for Keyboard

Screenshots or screencast

[github-actions]

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.

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: ellatrix <[email protected]>
Co-authored-by: priethor <[email protected]>
Co-authored-by: vcanales <[email protected]>

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

[github-actions]

This pull request changed or added PHP files in previous commits, but none have been detected in the latest commit.

Thank you! ❤️

[vcanales]

...make sure that core backport PRs are created as soon as a change is merged in GB that requires a backport.

I understand this as the PR has to be created and added to the changelog before the change is merged into PR, no? Apologies if this sounds pedantic, I'm just a bit confused by the order of operations :)

Maybe this PR obsoletes the other PHP change detection test.

Perhaps a combination rather than a replacement? I think it makes sense to have only one comment addressing PHP changes that need to be Backported and added to the changelog.

[ellatrix]

Changed the wording

Perhaps a combination rather than a replacement? I think it makes sense to have only one comment addressing PHP changes that need to be Backported and added to the changelog.

Yes, we can keep both if it's useful

[github-actions]

Flaky tests detected in 306f737.
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.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/9162267686
📝 Reported issues:

• [Flaky Test] Redirection after template creation #60678 in /test/e2e/specs/site-editor/site-editor-url-navigation.spec.js

[priethor]

It's a good, low-risk first attempt, and I see no reason not to try it and iterate later.

[ellatrix]

Let's try this at least until the middle of the next release and see if there are benefits. We can add more ignored paths if necessary.

[ramonjd]

This PR introduces a test that checks if an entry with a core backport PR has been added to the backport changelog.

Hi there!

Thanks for this - going to help with release season for sure.

Quick question: is there a way to opt-out for PHP changes that don't require backports, e.g., PRs that sync from Core -> Gutenberg

Or this one I'm working on

• Site Export: ensure that the export endpoint uses Gutenberg theme classes #61561

[ramonjd]

Quick question: is there a way to opt-out for PHP changes that don't require backports, e.g., PRs that sync from Core -> Gutenberg

A "try" branch here skipping via a label:

• Workflows: test to check for label and skip backport changelog #61808