-
Notifications
You must be signed in to change notification settings - Fork 454
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Auto-Labeling for Issues using GitHub Actions #5136
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Vineet1101 <[email protected]>
I, Vineet1101 <[email protected]>, hereby add my Signed-off-by to this commit: 796accb Signed-off-by: Vineet1101 <[email protected]>
@fruffy @jafingerhut please review this pr |
.github/workflows/auto-label.yml
Outdated
|
||
// Define keyword-label mapping | ||
const labelMappings = { | ||
"bug": "bug", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's use brackets here, eg [frontend]. Is this case insensitive? Also do not use the body. The title is good enough. Otherwise you will get many, many false positives with this approach.
Also, only use labels that make sense. For example, why would someone tag their issue [duplicate]
or [question]
?
There are some other ones which are useful.
[P4Testgen] -> p4tools tag.
[P4Smith] -> p4tools tag.
[P4tools] -> p4tools tag.
In general, try to take a look at how the labels are currently used for issues and try to reflect this mapping.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fruffy I don't get what exactly you mean by [frontend] like the actions should check for [bug] in the title instead of bug??
Yes it is case sensitive but I have updated the code so now it is case insensitive and I have also included more labels
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For example, this PR uses frontend and the label is core.
#5133
Because the frontend, midend, parser, etc are all part of the compiler core.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so if we apply [frontend] like this I think it will not work properly as many people will not mention [] while writing the title for their issue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, we can use frontend or front end in the title, but we have to be careful about false positives. [Frontend] is rather safe.
Another example is this issue:
This issue can be tagged tofino and bug because it has a compiler bug label and tofino in the title.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about we apply regex to match exactly from the tittle. For false positive maybe we can use a priority list so that the one's with higher priority gets label and one more thing I would like to ask is I don't get your point with [Frontend] I mean while writing the title of a issue people will simple write frontend they will not enclose it in brackets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one more solution that I can think is using weighted keyword matching
const labelMappings = { "compiler-core": { keywords: ["frontend", "midend", "parser", "backend"], threshold: 1 }, "networking": { keywords: ["dpdk", "ebpf", "switching"], threshold: 1 }, };
in this if threshold crosses 1 the compiler-core will get applied if not then parser or whatever written in the title will get applied. We can apply strict checking using regex to avoid false positive.
What are your thoughts on this idea @fruffy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mean while writing the title of a issue people will simple write frontend they will not enclose it in brackets.
A lot of developers actually do this. Especially once a keyword will automatically lead to labelling.
What are your thoughts on this idea @fruffy
Multiple labels are actually ok. I would take a look at the current labels we have and then decide how these should be assigned. Feel also free to ask on what these labels mean.
This could also be part of documentation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok for now I will add brackets also and once you have checked and decided tell me I will make changes according to that. I think we should also mention somewhere this thing in docs or something that one should use [] to auto add labels
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, let's do that!
Signed-off-by: Vineet1101 <[email protected]>
.github/workflows/auto-label.yml
Outdated
"[p4c]": "p4c", | ||
"[bmv2]": "bmv2", | ||
"[compiler]": "compiler", | ||
"[test]": "testing", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not a label.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like compiler and testing are still there, both of these are not labels.
.github/workflows/auto-label.yml
Outdated
"[feature]": "enhancement", | ||
"[docs]": "documentation", | ||
"[dpdk]": "dpdk", | ||
"[p4c]": "p4c", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is also not an existing label.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have removed that non existing labels
.github/workflows/auto-label.yml
Outdated
"[bug]": "bug", | ||
"[error]": "bug", | ||
"[fix]": "bug", | ||
"[feature]": "enhancement", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could also be feat
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you mean in addition to [feature] we should also add [feat] and both will map to enhancement??
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For example, yes. You could have multiple variants.
.github/workflows/auto-label.yml
Outdated
"[Tofino]":"tofino", | ||
"[p4tc]": "p4tc", | ||
"[p4fmt]": "p4fmt", | ||
"[core]":"core", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This list is missing some more labels:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fruffy can you please clear this doubts so that I can make changes accordingly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am currently traveling with limited access to internet. I will give this a thorough look later. run-xyz
you do not need to map.
For the other labels you should take a look at the issues that are being tagged with them and see whether you can find a mapping that works.
@fruffy any suggestions you would like to give
|
You do not have to worry about labels such as run-ubuntu18 or run-sanitizer. These are for pull request to run specific workflows. |
Signed-off-by: Vineet1101 <[email protected]>
Signed-off-by: Vineet1101 <[email protected]>
@fruffy I have made the changes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks ready to me. @Vineet1101 could you update the video to reflect the latest version?
This should get a pair of second eyes, too. @jafingerhut this PR adds an auto-labelling feature for issues and PRs. Using certain keywords in the title should automatically add tags now.
@fruffy ya sure I will update the video but I thing i would like to suggest is that we should mention somewhere that one can use [bug] like this thing title to automatically add labels |
The best way to do this is probably as a hint in an issue template. We do not have these templates yet. |
@fruffy one more thing for now this file only self tags issue do you want this on pull request also?? |
Hey @fruffy can you please tell if you want this auto labelling feature on pr also so that I can modify the code a little bit |
Yeah for PRs these tags also make sense. Except bug, question, enhancement or similar. |
Signed-off-by: Vineet1101 <[email protected]>
@fruffy I modified to the code to auto label pr as well you can review it whenever you have time. I have also updated the pr description |
Automatic Issue and PR Labeling System
Overview
This feature provides an automated labeling system for GitHub issues and pull requests based on standardized tags in their titles. The system automatically detects bracketed keywords in titles and applies corresponding labels, streamlining triaging and categorization of contributions.
How It Works
When an issue or pull request is created or edited, the GitHub Action workflow analyzes its title for bracketed keywords (e.g.,
[bug]
,[feature]
,[core]
) and automatically applies the relevant labels to the item. This reduces manual labeling work for maintainers and ensures consistent categorization.Screencast.from.2025-03-08.06-23-23.mp4
Supported Tags
For Both Issues and PRs
The system recognizes the following tags in both issue and PR titles:
[core]
→ "core"[midend]
→ "core"[parser]
→ "core"[dpdk]
→ "dpdk"[bmv2]
→ "bmv2"[P4Testgen]
→ "p4tools"[P4Smith]
→ "p4tools"[P4tools]
→ "p4tools"[Tofino]
→ "tofino"[p4tc]
→ "p4tc"[p4fmt]
→ "p4fmt"[p4-spec]
→ "p4-spec"[control-plane]
→ "control-plane"[P4runtime]
→ "control-plane"[docs]
/[documentation]
→ "documentation"Additional Tags for Issues Only
Issues also support:
[bug]
→ "bug"[feature]
→ "enhancement"[frontend]
→ "core"Usage Guide
For Contributors
When creating an issue or pull request:
[bug][core] Fix memory leak in parser
)[bmv2]
,[BMV2]
, and[Bmv2]
all workExample issue title:
Example PR title:
For Maintainers
Benefits
Technical Implementation
The feature is implemented as a GitHub Action workflow using the GitHub Script action. The workflow is triggered on issue and PR creation/editing events and uses the GitHub API to apply appropriate labels.
The workflow: