allod/tools
2
0
Fork 0
Code Issues 13 Pull requests Projects Releases Packages Wiki Activity Actions

Add Forge issue organization commands #86

Merged
vnprc merged 3 commits from agent/forge-issue-organization into master 2026-07-07 16:19:23 +01:00
Conversation 6 Commits 3 Files changed 7 +1601 -60
vnprc commented 2026-07-06 23:50:54 +01:00
Owner
Copy link

Add forge support for organizing issue backlogs with labels and milestones.

Scope:

  • Add repository label commands: list, create, edit, delete.
  • Add repository milestone commands: list, view, create, edit, delete.
  • Show labels and milestones in forge issue list and forge issue view.
  • Allow issue creation with labels and milestone assignment.
  • Add issue subcommands to list/change labels and show/set/clear milestones.
  • Document that project commands are unavailable when the Forgejo API does not expose repository project endpoints.

Acceptance:

  • Agents can triage issues from the CLI using labels and milestones.
  • Project support fails explicitly with a clear API limitation message instead of relying on brittle web automation.
  • Existing Forge PR, issue, auth, token, and close flows keep working.

Validation:

  • bash -n forge
  • tests/forge/*.sh
  • Live read-only smoke checks against allod/tools for label/milestone endpoints and project unavailability.

closes #85

Add `forge` support for organizing issue backlogs with labels and milestones. Scope: - Add repository label commands: list, create, edit, delete. - Add repository milestone commands: list, view, create, edit, delete. - Show labels and milestones in `forge issue list` and `forge issue view`. - Allow issue creation with labels and milestone assignment. - Add issue subcommands to list/change labels and show/set/clear milestones. - Document that project commands are unavailable when the Forgejo API does not expose repository project endpoints. Acceptance: - Agents can triage issues from the CLI using labels and milestones. - Project support fails explicitly with a clear API limitation message instead of relying on brittle web automation. - Existing Forge PR, issue, auth, token, and close flows keep working. Validation: - `bash -n forge` - `tests/forge/*.sh` - Live read-only smoke checks against `allod/tools` for label/milestone endpoints and project unavailability. closes #85
vnprc commented 2026-07-07 15:17:31 +01:00
Author
Owner
Copy link

do these commands match gh patterns?

do these commands match gh patterns?
allod-agent commented 2026-07-07 15:20:37 +01:00
Member
Copy link

Mostly, but not exact gh parity.

Matches or closely follows gh:

  • forge issue create -l/--label and -m/--milestone match gh issue create's label/milestone flags.
  • forge issue close -c/--comment, -r/--reason, and --duplicate-of match gh issue close.
  • Top-level forge label list/create/edit/delete follows the same resource/verb shape as gh label ....

Main differences I see:

  • gh label create is gh label create <name> [--color ... --description ...]; this PR uses forge label create --name <name> --color <hex>. That is consistent with the existing explicit forge create style, but not the same muscle memory as gh.
  • gh issue edit mutates labels and milestones inline with --add-label, --remove-label, --milestone, and --remove-milestone. This PR has forge issue labels ..., forge issue milestone ..., and issue edit --clear-milestone; those are reasonable Forge-specific helpers, but they are not the exact gh issue edit shape.
  • Current gh does not appear to have a top-level gh milestone porcelain command, so forge milestone ... is a Forge-specific backlog command rather than a gh mirror.
  • gh label list has list controls like --limit, --sort, --order, and --search; this implementation is narrower.

So my read is: yes for the general command grammar and the most important issue/label flags, no for strict parity. If exact gh muscle memory is the goal, I would add the gh issue edit label/milestone flags and consider making label create <name> work as an alias for label create --name <name>. Otherwise, I would document these as deliberate forge departures.

Mostly, but not exact `gh` parity. Matches or closely follows `gh`: - `forge issue create -l/--label` and `-m/--milestone` match `gh issue create`'s label/milestone flags. - `forge issue close -c/--comment`, `-r/--reason`, and `--duplicate-of` match `gh issue close`. - Top-level `forge label list/create/edit/delete` follows the same resource/verb shape as `gh label ...`. Main differences I see: - `gh label create` is `gh label create <name> [--color ... --description ...]`; this PR uses `forge label create --name <name> --color <hex>`. That is consistent with the existing explicit `forge` create style, but not the same muscle memory as `gh`. - `gh issue edit` mutates labels and milestones inline with `--add-label`, `--remove-label`, `--milestone`, and `--remove-milestone`. This PR has `forge issue labels ...`, `forge issue milestone ...`, and `issue edit --clear-milestone`; those are reasonable Forge-specific helpers, but they are not the exact `gh issue edit` shape. - Current `gh` does not appear to have a top-level `gh milestone` porcelain command, so `forge milestone ...` is a Forge-specific backlog command rather than a `gh` mirror. - `gh label list` has list controls like `--limit`, `--sort`, `--order`, and `--search`; this implementation is narrower. So my read is: yes for the general command grammar and the most important issue/label flags, no for strict parity. If exact `gh` muscle memory is the goal, I would add the `gh issue edit` label/milestone flags and consider making `label create <name>` work as an alias for `label create --name <name>`. Otherwise, I would document these as deliberate `forge` departures.
allod-agent commented 2026-07-07 15:27:26 +01:00
Member
Copy link

Follow-up request from this review thread: update the new issue organization commands to match gh patterns as closely as Forgejo's API allows, push those changes to this PR, then run an independent code review pass, post the review results here, and address any findings in a follow-up commit.

Follow-up request from this review thread: update the new issue organization commands to match `gh` patterns as closely as Forgejo's API allows, push those changes to this PR, then run an independent code review pass, post the review results here, and address any findings in a follow-up commit.
allod-agent commented 2026-07-07 15:41:44 +01:00
Member
Copy link

Independent review pass after dc4dde9 found the following:

  • High: forge label delete <name> accepts --yes but does not require it or prompt before deletion. The help/docs present --yes as the confirmation bypass, matching gh label delete, so the current behavior is more destructive than the public contract implies.
  • Medium: forge issue list applies label/milestone/search filters only after fetching the unfiltered --limit results. That can omit matching issues outside the first page; Forgejo exposes server-side issue query params for this.
  • Low: comma splitting accepts a trailing comma such as bug, because Bash drops the trailing empty field, even though interior empty values are rejected.

Validation from the review agent: read-only diff review, git diff --check master...HEAD, bash -n forge tests/forge/*.sh, executable Forge tests, and bash tests/forge/pr-close.sh. shellcheck was not installed.

I am fixing these in a follow-up commit.

Independent review pass after `dc4dde9` found the following: - High: `forge label delete <name>` accepts `--yes` but does not require it or prompt before deletion. The help/docs present `--yes` as the confirmation bypass, matching `gh label delete`, so the current behavior is more destructive than the public contract implies. - Medium: `forge issue list` applies label/milestone/search filters only after fetching the unfiltered `--limit` results. That can omit matching issues outside the first page; Forgejo exposes server-side issue query params for this. - Low: comma splitting accepts a trailing comma such as `bug,` because Bash drops the trailing empty field, even though interior empty values are rejected. Validation from the review agent: read-only diff review, `git diff --check master...HEAD`, `bash -n forge tests/forge/*.sh`, executable Forge tests, and `bash tests/forge/pr-close.sh`. `shellcheck` was not installed. I am fixing these in a follow-up commit.
allod-agent commented 2026-07-07 15:43:45 +01:00
Member
Copy link

Fixed the independent review findings in e8a8290:

  • label delete now requires --yes before resolving/deleting a label.
  • issue list now sends labels, milestones, and q to the Forgejo issue API instead of filtering only the first fetched page locally.
  • comma-separated label parsing now rejects trailing empty entries such as bug,.

Validation after the fixes:

  • bash -n forge
  • for t in tests/forge/*.sh; do bash "$t"; done
  • git diff --check
Fixed the independent review findings in `e8a8290`: - `label delete` now requires `--yes` before resolving/deleting a label. - `issue list` now sends `labels`, `milestones`, and `q` to the Forgejo issue API instead of filtering only the first fetched page locally. - comma-separated label parsing now rejects trailing empty entries such as `bug,`. Validation after the fixes: - `bash -n forge` - `for t in tests/forge/*.sh; do bash "$t"; done` - `git diff --check`
vnprc commented 2026-07-07 16:18:48 +01:00
Author
Owner
Copy link

I opened this PR under my own account using the allod patch tool. You can't approve your own PRs so I am manually merging to master.

I opened this PR under my own account using the `allod patch` tool. You can't approve your own PRs so I am manually merging to master.
vnprc merged commit e8a8290b43 into master 2026-07-07 16:19:23 +01:00
vnprc deleted branch agent/forge-issue-organization 2026-07-07 16:19:24 +01:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
allod/tools!86
No description provided.