opencode-forgekeeper 2.1.0 → 2.2.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +39 -14
- package/dist/index.js +543 -193
- package/dist/tui.js +263 -29
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -148,6 +148,11 @@ reuses a branch's PR/MR number for up to 10 minutes.
|
|
|
148
148
|
Explicit targets that aren't PRs/MRs, such as issues, show no status. Unresolved explicit
|
|
149
149
|
PRs/MRs never fall back to the branch.
|
|
150
150
|
|
|
151
|
+
Without a PR/MR to show, the footer stays empty, even when a lookup fails, such as in a new
|
|
152
|
+
session before the server answers. It shows `PR/MR status unavailable` only when none of
|
|
153
|
+
the session's explicit PR/MR targets can be looked up or found. `/forge-status` explains
|
|
154
|
+
why.
|
|
155
|
+
|
|
151
156
|
The server runs at most four `glab` or `gh` commands at once for status and review
|
|
152
157
|
feedback, across all sessions. When some target lookups fail, the footer shows the others
|
|
153
158
|
and counts the failures as `N unavailable`. A target whose lookup failed with an error
|
|
@@ -163,8 +168,8 @@ With several PR/MR targets, the footer shows counts instead of one PR/MR's statu
|
|
|
163
168
|
status dialog, which lists each PR/MR.
|
|
164
169
|
|
|
165
170
|
The footer shows checks or the pipeline, unresolved threads, conflicts, approval, and a
|
|
166
|
-
running GitLab Duo
|
|
167
|
-
unknown rather than appearing conflict-free.
|
|
171
|
+
running automated review, from GitLab Duo or GitHub Copilot. GitHub also shows a requested
|
|
172
|
+
change. Unknown mergeability stays unknown rather than appearing conflict-free.
|
|
168
173
|
|
|
169
174
|
The footer shows `approved` only when GitLab reports that approval requirements are met,
|
|
170
175
|
at least one person approved, and every human reviewer approved. Bot approvals, such as
|
|
@@ -227,16 +232,23 @@ Before it sends a notification, the server checks that the PR/MR is still one of
|
|
|
227
232
|
session's targets. A lookup that started before the targets changed is discarded, so a
|
|
228
233
|
removed target never triggers a notification.
|
|
229
234
|
|
|
230
|
-
| Notification | GitLab | GitHub
|
|
231
|
-
| ------------------------------------------ | ----------- |
|
|
232
|
-
| An automated review finished with feedback | GitLab Duo |
|
|
233
|
-
| New human review feedback | MR comments |
|
|
234
|
-
|
|
235
|
-
- **Automated reviews**: Duo's final state of `REVIEWED` or `REQUESTED_CHANGES`
|
|
236
|
-
agent to read its comments. Other final states, such as `APPROVED`, send nothing.
|
|
237
|
-
server notifies
|
|
238
|
-
finished before the server first saw it running isn't announced. Reviews that finish
|
|
239
|
-
the same poll share one message.
|
|
235
|
+
| Notification | GitLab | GitHub |
|
|
236
|
+
| ------------------------------------------ | ----------- | -------------- |
|
|
237
|
+
| An automated review finished with feedback | GitLab Duo | GitHub Copilot |
|
|
238
|
+
| New human review feedback | MR comments | PR comments |
|
|
239
|
+
|
|
240
|
+
- **Automated reviews**: for GitLab, Duo's final state of `REVIEWED` or `REQUESTED_CHANGES`
|
|
241
|
+
asks the agent to read its comments. Other final states, such as `APPROVED`, send nothing.
|
|
242
|
+
The server notifies when it sees a review go from running to finished, so a Duo review
|
|
243
|
+
that finished before the server first saw it running isn't announced. Reviews that finish
|
|
244
|
+
in the same poll share one message.
|
|
245
|
+
- **Copilot reviews**: the server notifies when a submitted, undismissed review has at least
|
|
246
|
+
one inline comment. A review without inline comments, such as one that
|
|
247
|
+
found nothing or couldn't run for lack of quota, sends nothing. Copilot reviews are
|
|
248
|
+
identified, so a review that started and finished between two polls is announced too. A
|
|
249
|
+
review that the server finds on a PR's first look isn't announced. Observed and delivered
|
|
250
|
+
review IDs persist across restarts. A completed review can be announced while another
|
|
251
|
+
review is requested.
|
|
240
252
|
- **Human reviews**: new comments and replies from people other than you and bots are
|
|
241
253
|
announced once none of their unresolved comments has changed for 5 minutes. Expect one
|
|
242
254
|
message 5 to 7 minutes after the review goes quiet. Resolved threads are skipped.
|
|
@@ -256,6 +268,17 @@ records. A failed storage write shows an error toast once.
|
|
|
256
268
|
On GitLab, the server reads the newest 2,000 comments. On busier MRs, edits to older
|
|
257
269
|
comments don't count as activity.
|
|
258
270
|
|
|
271
|
+
On GitHub, the server reads three lists: conversation comments, the text of submitted
|
|
272
|
+
reviews, and the inline comments of review threads. It keeps the newest 2,000 of each.
|
|
273
|
+
It scans every thread to include recent replies in old threads, within a limit of 200 API
|
|
274
|
+
requests per fetch. If it cannot complete that scan, it defers notifications until a complete
|
|
275
|
+
fetch succeeds. Review text counts when it isn't empty, whether the
|
|
276
|
+
review approves, requests changes, or only comments. Comments from GitHub Apps, such as
|
|
277
|
+
Copilot, count as bots. Hidden comments and unsubmitted review comments are skipped.
|
|
278
|
+
The baseline also records comment IDs at its timestamp, so a new comment posted in the same
|
|
279
|
+
second can still be announced. Baselines stored by older plugin versions retain their
|
|
280
|
+
timestamp-only behavior until a new baseline is created.
|
|
281
|
+
|
|
259
282
|
## Options
|
|
260
283
|
|
|
261
284
|
Set options with the object form of the `plugins` entry in `opencode.json`:
|
|
@@ -363,6 +386,8 @@ notifications resume the session. Set `reviewStatus` to `false` to keep only tit
|
|
|
363
386
|
`src/tui.tsx` connects it to the RPC and renders the footer, dialog, commands, and notices.
|
|
364
387
|
- `src/forge.ts` defines the forge-neutral types, the `Forge` adapter interface, and
|
|
365
388
|
`ForgeTraits` with its optional `automatedReview` and `feedback` capabilities.
|
|
389
|
+
- `src/gitlab-feedback.ts` and `src/github-feedback.ts` read each forge's comments for its
|
|
390
|
+
`feedback` capability.
|
|
366
391
|
- `src/gitlab.ts` and `src/github.ts` provide each forge's adapter and traits. Adapters own
|
|
367
392
|
API calls, pagination, error classification, and status normalization. Traits cover
|
|
368
393
|
everything else: hosts, URL parsing, reference syntax, vocabulary, and forge-specific
|
|
@@ -373,8 +398,8 @@ notifications resume the session. Set `reviewStatus` to `false` to keep only tit
|
|
|
373
398
|
- `src/locate.ts` picks each key's PRs/MRs. `src/store.ts` caches lookups, polls, backs off
|
|
374
399
|
after failures, and discards lookups that started before a change. `src/format.ts`
|
|
375
400
|
renders the footer and dialog.
|
|
376
|
-
- `src/automated-review-watch.ts
|
|
377
|
-
|
|
401
|
+
- `src/automated-review-watch.ts` and `src/human-review-watch.ts` decide when to notify the
|
|
402
|
+
agent.
|
|
378
403
|
|
|
379
404
|
Shared code never compares a forge against a specific name. It asks the forge's traits, or
|
|
380
405
|
checks for a capability, instead. To add a forge, add its kind to `ForgeKind` and
|