-
Notifications
You must be signed in to change notification settings - Fork 30
feat: Add GitHub issue automation with issue metadata #350
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
base: main
Are you sure you want to change the base?
feat: Add GitHub issue automation with issue metadata #350
Conversation
- Add GitHub Actions workflow for automated issue processing - Implement project field management for GitHub Projects v2 - Add task labeller action for issue categorization - Enhance GitHub tools with optimized project operations - Add automation configuration for issue metadata
- Remove automatic Status field setting to Todo - Only update the specifically requested project field - Remove debug logging and incomplete functions
- Update system prompt to tag only the 2 most related experts - Prioritize experts most closely related to specific issue content - Reduce notification noise while maintaining relevant expertise
39cd167 to
7a6ba30
Compare
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.
Can we have some examples of this working? I'd like to evaluate it before adding this
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.
Action: https://github.com/JackYPCOnline/sdk-typescript/actions/runs/20180281490/job/57938749701
Issue: JackYPCOnline#12
Are you able to access the links?
| "name": "Gemini Model Provider", | ||
| "github_usernames": ["notgitika"] | ||
| }, | ||
| "litellm": { |
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.
Would it be better to list the the label associated with the category? Or are we allowing any label?
Right now all of our "area" label start with "area-"
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 labels, the agent will only use existing labels. It will @ the person in this list in the comment, thus the expert will receive an email noticification. We can do assign the expert directly, but personally I think this is a little aggressive.
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.
Agreed, we shouldn't assign. I like mentioning more.
But we do have to be concerned with user-submitted content possibly spamming the repository via the agent. Some sort of guard rails around what the agent can do I think would be ideal.
| Returns: | ||
| Result of the operation | ||
| """ | ||
| result = _github_request("POST", f"issues/{issue_number}/labels", repo, {"labels": 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.
Similar question to above, I wonder if we should be validating that the label is allow-listed to the subset of "known" labels.
Alternatively, we should validate/require that the label already exists
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 agent pull existing labels only and apply them, it can create labels if we adjust system prompt.
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 agent pull existing labels only and apply them
Can you trick it into applying 200 new labels? And on unrelated issues?
| types: [opened,reopened] | ||
| permissions: | ||
| contents: write | ||
| issues: write |
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.
We should be architecting this similar to the existing agents. Right now, we have two stages:
- Agent runs in a readonly sandbox
- A sub-subsequent job/stage takes the output of (1) and updates writable things as appropriate. This is to help avoid the agent from having too many permissions, like updating unrelated PRs & Issues. I think we should be doing the same thing here.
|
|
||
| on: | ||
| issues: | ||
| types: [opened,reopened] |
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.
We don't currently have any workflows that run agents automatically and on arbitrary issues. We'll have to evaluate how we do this. Right now all agents are "opt-in" while this is "automatic on all" which has some security concerns I think
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.
That is an interesting topic we need to think about since we want an agent to be automated.
Description
This RP helps add issue metadata, help identify and summerize the issue, then tag the area of expert in the comments.
Tested in my fork.
Related Issues
Hack day feature.
Documentation PR
Type of Change
Bug fix
New feature
Breaking change
Documentation update
Other (please describe):
Testing
How have you tested the change?
npm run checkChecklist
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.