| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Add a feature-flagged batch labeling tool that applies add/remove label
operations to multiple issues in a single MCP call, avoiding N sequential
update_issue_labels round-trips for bulk triage workflows (e.g. 'label all
issues from milestone X as priority/high').
- Each operation entry targets one issue with add and/or remove arrays;
labels not named in the operation are left untouched.
- All input is validated before any mutation: empty operations, duplicate
issue numbers, missing add/remove, and empty label names fail the whole
call up front. Per-issue API errors are reported individually in the
JSON result with applied/error per issue.
- Add phase uses POST /issues/{n}/labels (additive) and returns the full
resulting label set; remove phase uses DELETE per label.
Closes github#2412
|
Rebased the unchanged implementation onto current main (febc3293); the new head is 46f9a99e. The branch is now current and ready for review. Existing focused/full pkg/github verification remains as described in the PR body (environment-only Windows golden snapshot failures reproduce on clean main). |
Sorry, something went wrong.
|
After the rebase, the current main scope API required inventory.ScopeAccess; I updated the batch tool to use the repository's standard scopes.RequireAll(scopes.Repo) helper. The focused batch-label and granular-tool tests pass, go vet ./pkg/github/... passes, and the pushed head is d4711bfc. AI assistance was used for this contribution. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Closes #2412
Summary
Adds a feature-flagged granular tool batch_update_issue_labels that applies label changes to multiple issues in a single MCP call. Today the only path for bulk labeling is N sequential update_issue_labels calls, which is exactly the friction described in #2412 (label all issues from milestone X as priority/high forces either N noisy round-trips or dropping out of the MCP-first pattern to script the gh CLI).
Design
The add phase returns GitHub's full resulting label set per issue, so callers can verify final state without a follow-up read.
This follows the existing granular-tools pattern: registered in the issues toolset, gated behind FeatureFlagIssuesGranular, mutually exclusive with the consolidated issue_write.
Testing
Example
{ "owner": "org", "repo": "repo", "operations": [ {"issue_number": 10, "add": ["sprint-42"]}, {"issue_number": 15, "add": ["breaking-change"], "remove": ["needs-triage"]}, {"issue_number": 20, "remove": ["stale"]} ] }