Tag dotnet/jit-contrib for JIT related changes#116589
Conversation
github-actions
Bot
added
the
needs-area-label
|
cc @dotnet/jit-contrib |
There was a problem hiding this comment.
Pull Request Overview
This PR adds a new policy rule to automatically tag the @dotnet/jit-contrib team on PRs that touch JIT-related files under src/coreclr.
- Introduces a conditional block matching JIT file paths in
resourceManagement.yml - Configures the bot to mention
@dotnet/jit-contribwithout assigning them - Provides a custom reply template and description for clarity
Comments suppressed due to low confidence (3)
.github/policies/resourceManagement.yml:1682
- Consider refining the regex with word boundaries (e.g.,
(?i)src/coreclr/.*\bjit\b.*) to avoid unintended matches like filenames containing 'jit' as a substring.
pattern: (?i)src/coreclr/.*jit.*
.github/policies/resourceManagement.yml:1692
- [nitpick] For consistency with YAML boolean styling used elsewhere, consider using lowercase
falseinstead ofFalse.
assignMentionees: False
.github/policies/resourceManagement.yml:1693
- [nitpick] Update the description to explicitly mention
@dotnet/jit-contriband hyphenate 'JIT-related' for clarity, e.g.,Mention @dotnet/jit-contrib for JIT-related changes.
description: '@Mention for JIT related changes'
jkotas
added
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
| - if: | ||
| - payloadType: Pull_Request | ||
| - filesMatchPattern: | ||
| pattern: (?i)src/coreclr/.*jit.* | ||
| matchAny: true | ||
| - isPullRequest | ||
| - isOpen | ||
| then: | ||
| - mentionUsers: | ||
| mentionees: | ||
| - dotnet/jit-contrib | ||
| replyTemplate: >- | ||
| Tagging @dotnet/jit-contrib for JIT-related changes | ||
| assignMentionees: False | ||
| description: '@Mention for JIT-related changes' |
There was a problem hiding this comment.
Is this going to double tag for issues/prs that are getting the area-codegen label?
Don't think it'd be a big issue either way, but it might be a bit of extra noise that shows up if it does.
There was a problem hiding this comment.
Actually, I guess that's just tagging Julie/Jakob today and not jitcontrib, so shouldn't be an issue.
There was a problem hiding this comment.
@jakobbotsch Feel free to tweak this policy any way you want to fit the JIT team workflows.
|
The problem that codegen-area is the most popular tag in the whole repo https://github.com/dotnet/runtime/labels?sort=count-desc 😢 so it's hard to distinguish calls for help vs automated pings. |
Agree, at one point I subscribed myself of getting tagged for codegen-area alon with Julie/Jakob, but then soon realized that there are so many notifications that I was missing the tags in issues that needed my attention and so I went ahead and unsubscribed myself from that. |
This change is only adding the mention for PRs, not issues. I agree that for issues the amount of traffic is pretty high, but for PRs I think it's more reasonable that the JIT team is tagged. |
|
If other JIT team members are unhappy about being tagged on the JIT PRs we can change this PR to tag JIT members only on the JIT-EE GUID updates (that was what sparked my original comment). I think everyone on @dotnet/jit-contrib would be happy about being notified of JIT-EE GUID updates. Anyone against that @dotnet/jit-contrib? The automated area tagging usually works fine for JIT changes and people can opt in to that one. |
I do not mind either option, but would prefer the latter I personally scan all issues/prs anyway and use mail notification only to catch cases when our team is explicitly mentioned for an opinion/review. If I get more pings I'll most likely just redirect them to a folder.. |
Yeah GUID updates are the main thing, they can be disruptive to our workflows; we may miss SPMI coverage in CI or have to wait for relatively slow local downloads after merges from main. |
|
/ba-g Helix Queue Insights stuck |
No description provided.