feat: handle successive review requests in PRs #165
Labels
No labels
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
projects/forgejo-agent#165
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
@ci-bot can you give some suggestions on how to handle the case? I think the agent should be made aware of what it has already reviewed, and any resolutions applied.
Here's how I'd handle successive review requests, and I've implemented it in PR #263.
Approach
On a
pull_request_review_requestedevent, the agent should be given the history of its previous reviews on that PR, so it can:Implementation (PR #263)
src/schemas.ts— extendedprReviewSchema(author, verdict, commit, submitted_at) andprReviewCommentSchema(author, path, line, created_at); addedprReviewWithCommentsSchema.src/forgejo/index.ts— newgetPrReviewsWithComments()that fetches all PR reviews together with their inline comments.src/context.ts— onpull_request_review_requested, fetches the previous reviews and exposes them in the event context.src/prompt.ts— renders a "previous reviews" section (state, commit, body, and each inline comment with path/line) and adds guidance for successive reviews: check whether previously raised issues are resolved, re-raise what's still open, and look for new issues.The reviews are only fetched for review-request events, so other event types keep the same behavior and API footprint.