Add automation to label manual backports (#76579)

[Witheast]

What?

This PR adds a new GitHub Action workflow to automatically label original Pull Requests when a manual backport (cherry-pick) is merged into a release branch.

Closes #76579

Why?

Currently, when a manual cherry-pick is performed, it's easy to forget to add the Backported to label on the original PR. This automation ensures those PRs are correctly tracked for release notes and documentation.

How?

Created .github/workflows/manual-backport-labeler.yml which:

1. Triggers on merged PRs to wp/* or release/* branches.
2. Scans the PR body for the pattern backport of #12345.
3. Adds the corresponding label to the original PR.

Testing Instructions

1. This is a workflow change. I have verified the regex logic /(?:backport of|cherry-pick of) #(\d+)/i against sample strings.
2. To test in production, a PR must be merged into a release branch with the "Backport of #number" string in the description.

[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.

Unlinked Accounts

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

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: Witheast.

Co-authored-by: desrosj <desrosj@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]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @Witheast! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[Witheast]

Hi @desrosj, the 'Enforce labels' check is failing because I don't have permissions to add labels to the PR. Could you please add the [Type] Build Tooling label so the checks can pass? Everything else seems ready for review. Thanks!

[desrosj]

Thanks for taking a pass at this, @Witheast!

I would very much prefer not having to introduce a new workflow for this. An additional job or step within the cherry-pick-wp-release.yml workflow is preferred here.

Could you also provide some background on the different ways you considered detecting which PR is being cherry-picked? Thinking about this more, the merge commit messages should always have the PR number listed in the short description. For example,

Feat: Block Library: Improve the design of MediaControlPreview and MediaControl (https://github.com/WordPress/gutenberg/pull/76430)

I think that will likely be the most reliable way to detect which PR a cherry-pick belongs to without requiring a specific string to be included in the PR description (which is error prone and can be forgotten). But I'd like to understand all the possible options before going that route.

[Witheast]

Feat: Block Library: Improve the design of MediaControlPreview and MediaControl (#76430)

Thanks for the feedback! I agree that integrating this into the existing cherry-pick-wp-release.yml workflow is much cleaner.

Regarding the detection method, I initially considered parsing the PR description, but I agree that it's error-prone. Another option I looked into was using the GitHub GraphQL API to find referenced PRs, but parsing the merge commit message for the (#PR_NUMBER) string is definitely the most robust and straightforward approach for Gutenberg's workflow.

I'll work on moving the logic into a new job within the existing workflow and switch to commit-message detection. I'll update the PR shortly!

[Witheast]

I’ve updated the PR to integrate the logic directly into cherry-pick-wp-release.yml as requested.

The script now extracts the PR number directly from the merge commit message using git log. This avoids relying on the PR description and follows the 'source of truth' detection we discussed. Ready for another look!