feat(issue): add `attachment` subcommand for issue attachments #54

Merged

David merged 2 commits from feat/issue-attachment-FJCLI-43 into main

2026-06-19 11:11:00 +02:00

David commented

2026-06-19 10:06:32 +02:00

Owner

fj issue could create and comment on issues but had no way to manage their attachments, so an agent or user filing an issue with fj could not attach evidence (a screenshot, a log file): the file had to be added by hand in the web UI. Mirror yt issue attachment with a new fj issue attachment group of add / list / get / remove, backed by Forgejo's Gitea-compatible issue-asset endpoints.

add <index> <file> [--name] uploads a local file via issue_create_issue_attachment (defaulting the asset name to the file name); list <index> lists each attachment's id, name, size, and download URL; get <index> <name|id> [--out] resolves the asset (name first, then numeric id) and downloads its bytes to a path or directory; remove <index> <asset_id> deletes by id. Every command honors the existing host selection (--host / --remote / remote inference) and the --format text|json / --json conventions; the server enforces the attachment size limit, so an oversized upload surfaces its error like the other subcommands.

forgejo-api exposes issue attachments only as metadata (no byte-download method, and the Forgejo client's inner reqwest client is private), so the byte download lives in fj-client (download_attachment) next to action_run_logs, reusing the host bearer token and following redirects with the Authorization header marked sensitive. The CLI-agnostic operations live in fj-core::issues; rendering, the clap tree, and the new Fluent messages stay in the binary, keeping the fj-client / fj-core MCP-reuse contract (no clap/crossterm/fluent) intact.

#FJCLI-43

Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com

`fj issue` could create and comment on issues but had no way to manage their attachments, so an agent or user filing an issue with `fj` could not attach evidence (a screenshot, a log file): the file had to be added by hand in the web UI. Mirror `yt issue attachment` with a new `fj issue attachment` group of `add` / `list` / `get` / `remove`, backed by Forgejo's Gitea-compatible issue-asset endpoints. `add <index> <file> [--name]` uploads a local file via `issue_create_issue_attachment` (defaulting the asset name to the file name); `list <index>` lists each attachment's id, name, size, and download URL; `get <index> <name|id> [--out]` resolves the asset (name first, then numeric id) and downloads its bytes to a path or directory; `remove <index> <asset_id>` deletes by id. Every command honors the existing host selection (`--host` / `--remote` / remote inference) and the `--format text|json` / `--json` conventions; the server enforces the attachment size limit, so an oversized upload surfaces its error like the other subcommands. `forgejo-api` exposes issue attachments only as metadata (no byte-download method, and the `Forgejo` client's inner reqwest client is private), so the byte download lives in `fj-client` (`download_attachment`) next to `action_run_logs`, reusing the host bearer token and following redirects with the `Authorization` header marked sensitive. The CLI-agnostic operations live in `fj-core::issues`; rendering, the clap tree, and the new Fluent messages stay in the binary, keeping the `fj-client` / `fj-core` MCP-reuse contract (no clap/crossterm/fluent) intact. #FJCLI-43 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

David added 1 commit

2026-06-19 10:06:32 +02:00

feat(issue): add attachment subcommand for issue attachments

Check / fmt + clippy + build + tests (pull_request) Successful in 37s

Details

262b6be5a1

`fj issue` could create and comment on issues but had no way to manage their attachments, so an agent or user filing an issue with `fj` could not attach evidence (a screenshot, a log file): the file had to be added by hand in the web UI. Mirror `yt issue attachment` with a new `fj issue attachment` group of `add` / `list` / `get` / `remove`, backed by Forgejo's Gitea-compatible issue-asset endpoints.

`add <index> <file> [--name]` uploads a local file via `issue_create_issue_attachment` (defaulting the asset name to the file name); `list <index>` lists each attachment's id, name, size, and download URL; `get <index> <name|id> [--out]` resolves the asset (name first, then numeric id) and downloads its bytes to a path or directory; `remove <index> <asset_id>` deletes by id. Every command honors the existing host selection (`--host` / `--remote` / remote inference) and the `--format text|json` / `--json` conventions; the server enforces the attachment size limit, so an oversized upload surfaces its error like the other subcommands.

`forgejo-api` exposes issue attachments only as metadata (no byte-download method, and the `Forgejo` client's inner reqwest client is private), so the byte download lives in `fj-client` (`download_attachment`) next to `action_run_logs`, reusing the host bearer token and following redirects with the `Authorization` header marked sensitive. The CLI-agnostic operations live in `fj-core::issues`; rendering, the clap tree, and the new Fluent messages stay in the binary, keeping the `fj-client` / `fj-core` MCP-reuse contract (no clap/crossterm/fluent) intact.

#FJCLI-43

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

David added 1 commit

2026-06-19 11:10:56 +02:00

Merge branch 'main' into feat/issue-attachment-FJCLI-43

Create release / Create release from merged PR (pull_request) Has been skipped

Details

Check / fmt + clippy + build + tests (pull_request) Successful in 55s

Details

66930e2093