jcarr
/
gemini-cli
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Srithreepo Fixes for Scheduled triage (#5158)

This commit is contained in:
Srinath Padmanabhan 2025-07-30 13:38:02 -07:00 committed by GitHub
parent 32b1ef3779
commit 21965f986c
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 102 additions and 84 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
.github/workflows/gemini-scheduled-issue-triage.yml vendored
View File

@ -59,7 +59,8 @@ jobs:
"run_shell_command(echo)", "run_shell_command(echo)",
"run_shell_command(gh label list)", "run_shell_command(gh label list)",
"run_shell_command(gh issue edit)", "run_shell_command(gh issue edit)",
"run_shell_command(gh issue list)" "run_shell_command(gh issue list)",
"run_shell_command(gh issue view)"
], ],
"telemetry": { "telemetry": {
"enabled": true, "enabled": true,
@ -68,22 +69,39 @@ jobs:
"sandbox": false "sandbox": false
} }
prompt: | prompt: |
You are an issue triage assistant. Analyze the current GitHub issues apply the most appropriate existing labels. Do not remove labels titled help wanted or good first issue. You are an issue triage assistant. Analyze the current GitHub issues apply the most appropriate existing labels.
Steps: Steps:
1. Run: `gh label list --repo ${{ github.repository }} --limit 100` to get all available labels. 1. Run: `gh label list --repo ${{ github.repository }} --limit 100` to get all available labels.
2. Review the issue title, body and any comments provided in the environment variables. 2. Check environment variable for issues to triage: $ISSUES_TO_TRIAGE (JSON array of issues)
3. Ignore any existing priorities or tags on the issue. Just report your findings. 3. Review the issue title, body and any comments provided in the environment variables.
4. Select the most relevant labels from the existing labels, focusing on kind/*, area/*, sub-area/* and priority/*. For area/* and kind/* limit yourself to only the single most applicable label in each case. 4. Ignore any existing priorities or tags on the issue.
6. Apply the selected labels to this issue using: `gh issue edit ${{ github.event.issue.number }} --repo ${{ github.repository }} --add-label "label1,label2"` 5. Select the most relevant labels from the existing labels, focusing on kind/*, area/*, sub-area/* and priority/*.
7. For each issue please check if CLI version is present, this is usually in the output of the /about command and will look like 0.1.5 6. Get the list of labels already on the issue using `gh issue view ISSUE_NUMBER --repo ${{ github.repository }} --json labels -t '{{range .labels}}{{.name}}{{"\n"}}{{end}}'
7. For area/* and kind/* limit yourself to only the single most applicable label in each case.
8. Give me a single short paragraph about why you are selecting each label in the process. use the format Issue ID: , Title, Label applied:, Label removed, ovearll explanation
9. Parse the JSON array from step 2 and for EACH INDIVIDUAL issue, apply appropriate labels using separate commands:
- `gh issue edit ISSUE_NUMBER --repo ${{ github.repository }} --add-label "label1"`
- `gh issue edit ISSUE_NUMBER --repo ${{ github.repository }} --add-label "label2"`
- Continue for each label separately
- IMPORTANT: Label each issue individually, one command per issue, one label at a time if needed.
- Make sure after you apply labels there is only one area/* and one kind/* label per issue.
- To do this look for labels found in step 6 that no longer apply remove them one at a time using
- `gh issue edit ISSUE_NUMBER --repo ${{ github.repository }} --remove-label "label-name1"`
- `gh issue edit ISSUE_NUMBER --repo ${{ github.repository }} --remove-label "label-name2"`
- IMPORTANT: Remove each label one at a time, one command per issue if needed.
10. For each issue please check if CLI version is present, this is usually in the output of the /about command and will look like 0.1.5
- Anything more than 6 versions older than the most recent should add the status/need-retesting label - Anything more than 6 versions older than the most recent should add the status/need-retesting label
8. If you see that the issue doesn’t look like it has sufficient information recommend the status/need-information label 11. If you see that the issue doesn’t look like it has sufficient information recommend the status/need-information label
- After applying appropriate labels to an issue, remove the "status/need-triage" label if present: `gh issue edit ISSUE_NUMBER --repo ${{ github.repository }} --remove-label "status/need-triage"`
- Execute one `gh issue edit` command per issue, wait for success before proceeding to the next
Process each issue sequentially and confirm each labeling operation before moving to the next issue.
Guidelines: Guidelines:
- Only use labels that already exist in the repository. - Only use labels that already exist in the repository.
- Do not add comments or modify the issue content. - Do not add comments or modify the issue content.
- Do not remove labels titled help wanted or good first issue.
- Triage only the current issue. - Triage only the current issue.
- Apply only one area/ label - Apply only one area/ label
- Apply only one kind/ label - Apply only one kind/ label (Do not apply kind/duplicate or kind/parent-issue)
- Apply all applicable sub-area/* and priority/* labels based on the issue content. It's ok to have multiple of these. - Apply all applicable sub-area/* and priority/* labels based on the issue content. It's ok to have multiple of these.
- Once you categorize the issue if it needs information bump down the priority by 1 eg.. a p0 would become a p1 a p1 would become a p2. P2 and P3 can stay as is in this scenario. - Once you categorize the issue if it needs information bump down the priority by 1 eg.. a p0 would become a p1 a p1 would become a p2. P2 and P3 can stay as is in this scenario.
Categorization Guidelines: Categorization Guidelines:
@ -122,7 +140,7 @@ jobs:
- An edge-case bug that is very difficult to reproduce and affects a tiny fraction of users. - An edge-case bug that is very difficult to reproduce and affects a tiny fraction of users.
Qualifier: Is it a "nice-to-fix" issue? Qualifier: Is it a "nice-to-fix" issue?
Example: Spelling mistakes etc. Example: Spelling mistakes etc.
Things you should know. Additional Context:
- If users are talking about issues where the model gets downgraded from pro to flash then i want you to categorize that as a performance issue - If users are talking about issues where the model gets downgraded from pro to flash then i want you to categorize that as a performance issue
- This product is designed to use different models eg.. using pro, downgrading to flash etc. - This product is designed to use different models eg.. using pro, downgrading to flash etc.
- When users report that they dont expect the model to change those would be categorized as feature requests. - When users report that they dont expect the model to change those would be categorized as feature requests.