fj pr: label and assign on create and edit #114

New issue

Closed

opened 2026-06-11 00:08:49 +00:00 by stephen · 0 comments

stephen commented

2026-06-11 00:08:49 +00:00

Owner

Task

Let fj pr label and assign pull requests, mirroring the issue-side write surface:

--label / --assignee (repeatable, comma-split) on fj pr create, threaded into CreatePull (Forgejo's create-PR endpoint takes labels as IDs and assignees as logins; resolve label names to IDs via the labels API first).
--add-label / --remove-label / --add-assignee / --remove-assignee on fj pr edit, backed by the already-present but dormant add_to_issue / remove_from_issue (src/api/label.rs, drop the #[allow(dead_code)]) plus the parallel assignees endpoint. In Forgejo a PR is an issue, so POST /issues/{number}/labels labels a PR too.

Reuse whatever label-name→ID resolver lands for the issue side (rasterstate/fj#98) verbatim rather than duplicating it. A unified fj label add/remove <number> that works for both issues and PRs is an acceptable alternative shape.

Source: rasterstate/fj#110.

Priority

p2. Routing a PR (label area/api, assign the owner) is half of code-review triage and feeds everyone's filtered queues, pairing directly with the #108 filter work. gh-parity (gh pr create --label --assignee, gh pr edit --add-label). One notch below the p1s; the fj api fallback works today and this depends on the issue-side resolver.

Reason

fj pr covers reviewers (request-review/unrequest-review) but has no label/assignee write path: CreateArgs/EditArgs (src/cli/pr.rs) and CreatePull/EditPull (src/api/pull_core.rs) omit both. This is a write-only gap, not a data-model gap: Pull already deserializes labels on read, so fj pr view shows labels the CLI cannot set, and the label write endpoint already exists, just dormant. Distinct from #95/#98 (those are issue create/edit); this is the parallel hole on the PR surface.

Acceptance

fj pr create --label area/api --assignee alice opens a PR with the label and assignee set.
fj pr edit <n> --add-label needs-review --remove-label wip adds/removes PR labels.
fj pr edit <n> --add-assignee alice --remove-assignee bob adds/removes PR assignees.
An unknown label name errors clearly, naming the label.
The #[allow(dead_code)] on add_to_issue/remove_from_issue is removed (now reached by a CLI verb).
Wiremock coverage for the PR label/assignee add/remove and create calls.
cargo fmt --check, cargo clippy --all-targets --all-features -- -D warnings, and cargo test --all pass.

Dependencies

rasterstate/fj#98 (issue-side add/remove labels/assignees). Shares the label-name→ID resolver and the add/remove endpoint plumbing; land after or alongside #98 and reuse its resolver. Can also be folded into a shared fj label add/remove verb covering both surfaces.

Size

## Task Let `fj pr` label and assign pull requests, mirroring the issue-side write surface: - `--label` / `--assignee` (repeatable, comma-split) on `fj pr create`, threaded into `CreatePull` (Forgejo's create-PR endpoint takes `labels` as IDs and `assignees` as logins; resolve label names to IDs via the labels API first). - `--add-label` / `--remove-label` / `--add-assignee` / `--remove-assignee` on `fj pr edit`, backed by the already-present but dormant `add_to_issue` / `remove_from_issue` (`src/api/label.rs`, drop the `#[allow(dead_code)]`) plus the parallel assignees endpoint. In Forgejo a PR is an issue, so `POST /issues/{number}/labels` labels a PR too. Reuse whatever label-name→ID resolver lands for the issue side (`rasterstate/fj#98`) verbatim rather than duplicating it. A unified `fj label add/remove <number>` that works for both issues and PRs is an acceptable alternative shape. Source: `rasterstate/fj#110`. ## Priority p2. Routing a PR (label `area/api`, assign the owner) is half of code-review triage and feeds everyone's filtered queues, pairing directly with the `#108` filter work. gh-parity (`gh pr create --label --assignee`, `gh pr edit --add-label`). One notch below the p1s; the `fj api` fallback works today and this depends on the issue-side resolver. ## Reason `fj pr` covers reviewers (`request-review`/`unrequest-review`) but has no label/assignee write path: `CreateArgs`/`EditArgs` (`src/cli/pr.rs`) and `CreatePull`/`EditPull` (`src/api/pull_core.rs`) omit both. This is a write-only gap, not a data-model gap: `Pull` already deserializes `labels` on read, so `fj pr view` shows labels the CLI cannot set, and the label write endpoint already exists, just dormant. Distinct from `#95`/`#98` (those are issue create/edit); this is the parallel hole on the PR surface. ## Acceptance - [ ] `fj pr create --label area/api --assignee alice` opens a PR with the label and assignee set. - [ ] `fj pr edit <n> --add-label needs-review --remove-label wip` adds/removes PR labels. - [ ] `fj pr edit <n> --add-assignee alice --remove-assignee bob` adds/removes PR assignees. - [ ] An unknown label name errors clearly, naming the label. - [ ] The `#[allow(dead_code)]` on `add_to_issue`/`remove_from_issue` is removed (now reached by a CLI verb). - [ ] Wiremock coverage for the PR label/assignee add/remove and create calls. - [ ] `cargo fmt --check`, `cargo clippy --all-targets --all-features -- -D warnings`, and `cargo test --all` pass. ## Dependencies `rasterstate/fj#98` (issue-side add/remove labels/assignees). Shares the label-name→ID resolver and the add/remove endpoint plumbing; land after or alongside #98 and reuse its resolver. Can also be folded into a shared `fj label add/remove` verb covering both surfaces. ## Size M

stephen added the

backlog

labels

2026-06-11 00:09:06 +00:00

stephen referenced this issue from a pull request that will close it,

2026-06-11 00:22:56 +00:00

Add PR label and assignee support #117

stephen closed this issue

2026-06-11 00:36:18 +00:00

stephen referenced this issue

2026-06-11 00:46:10 +00:00

fj pr cannot label or assign a pull request (create or edit), though it can request reviewers #110