Project management: automate adding package-related labels to PRs#52729
Conversation
|
Flaky tests detected in dc4d694. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/18982729378
|
jordesign
left a comment
There was a problem hiding this comment.
It's beyond my skillset to comment on the code itself - but in terms of the labels being added it looks good to me
|
Thanks for taking a look, @jordesign . There are some label mismatches between the current labels and packages, as I noted in the spreadsheet from #52583. Since package labels should be a direct 1:1 mapping, I will move forward to updating them if you don't mind. |
apeatling
left a comment
There was a problem hiding this comment.
This looks great, and should help the problem quite a bit. Looks thorough to me but I will hold off on approval until you have the label mismatches sorted.
|
Slightly unrelated and maybe it would have been better addressed in the contrext of #52583 I just noticed that there's no label for the existing package Actual use case: I'd need the missing label to be added to #54148 |
9973baa to
2236c90
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 Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @apeatling. 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. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
| @@ -0,0 +1,255 @@ | |||
| # Package labeling rules - only labels that exist on GitHub | |||
There was a problem hiding this comment.
Is there any way to automate this list? Looking quickly, it seems that the part of the label after [Package] can just be coerced into lowercase and spaces replaced with hyphens to construct the directory path. For example, [Package] API Fetch -> packages/api-fetc/**. The only one where this is not the case is the [Package] E2E Tests.
We just removed a manually-curated list in #72672, so want to make sure that adding a new file for something similar is the desired solution.
I don't know if this is possible, but what if there was a step prior to this one that queried for all of the active [Package] labels for the repository and then created this file or a list on the fly each time?
There was a problem hiding this comment.
Yeah, I think it can be done, there are only a few exceptions like e2e and some typos that can be fixed at the label level.
I'd be happy to attempt that in a follow-up, to get this up and running first and see how it works before investing too much time in that. At the end of the day, label mismatches won't harm PRs as opposed to the Type-label enforcer, which would leave annoying messages and block merging.
There was a problem hiding this comment.
Actually:
- I've fixed the two labels that had a typo/mismatch
- For the exceptions, we can use the label description as a backup. They contain the patch of the package they should be "assigned" to, so we can use label descriptions to do the match in the workflow.
What?
This PR automates adding package-related labels to PRs when they affect one or more npm packages. Related discussions in #52583 and #52727 (comment)
Why?
Labeling in detail is a burden, and often PRs get merged without many labels. Some labels can be automated, like package labels and many feature-related ones.
How?
By adding a labeler GitHub action that checks the path of the files affected by the PRs.
Testing Instructions
I've created a PoC in a test repository, and it seems to work fine!