| Filename | Latest commit message | Latest commit date |
|---|---|---|
cdac6091eb
`ci-log --run <n> --job <idx>` accepted any index and exited 0. Past the
run's job count it printed job 0's log, with nothing marking the
substitution. Measured against run 3363 (4 jobs): indices 0-3 gave three
distinct md5s, while 99 and 12345 both returned output byte-identical to
job 0.
Both web log routes clamp an out-of-range index to job 0 and answer 200.
I had claimed nothing in the response distinguishes them -- that was
measured on the body only, and the body was the wrong place to look. The
`Content-Disposition` header names the job the server actually served:
--job 3 -> filename="ci-doc-pointer lint-8363.log"
--job 99 -> filename="ci-nix flake check-8360.log" (job 0's)
So the fix is to report what came back rather than to pre-validate the
index. Establishing the real job count needs two extra API calls on every
indexed read -- `ActionRun` carries no job count, and the only job
endpoints are the per-run listing and a per-job log keyed by internal job
id, not by index. The header costs nothing: it is already in the response
being read.
The provenance line goes to stderr, so it cannot corrupt a piped log;
under `--json` it is a `served` field instead. An out-of-range `--job` is
therefore no longer an error -- it is a read whose true subject is named.
`get_bytes_named` is a sibling of `get_bytes_raw` rather than a signature
change, leaving the attachment and artifact download paths untouched.
Rebased onto main after the two flat-rename PRs landed; the only conflict
was the test module's import list, resolved by keeping both sides. While
reading the surrounding context this commit's own defect surfaced:
`check_status`'s doc comment had been left glued to the head of
`disposition_filename`'s, so one function carried two unrelated
descriptions and the other carried none. No gate can see that -- it is
well-formed rustdoc either way.
|
||
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
hive-forge
Typed CLI wrapper around the in-cluster Forgejo's REST API — issues,
PRs, comments, labels, reviews, CI status, attachments, triage.
Replaces the old bash-script wrapper so agents and operators get
consistent error handling, exit codes, and JSON shapes. This is the
only supported path to the forge from inside an agent container;
never curl it directly.
Reads credentials from the environment (HIVE_FORGE_URL,
HYPERHIVE_STATE_DIR); -f/--forge <label> retargets a
dashboard-provisioned external forge account instead. The active repo
resolves -r/--repo > the origin remote of the cwd's git checkout >
HIVE_FORGE_REPO (last-resort override, unset by default) > a hard
error — see client::Client::from_env.
When to use it
Reach for this crate when adding or changing a forge verb — it's the
single place issue/PR/comment/CI logic lives for every agent and
hivectl. Adding a tool an agent's claude session calls is
hive-agent-mcp wrapping a shellout to this binary, not new logic
here.
Shape
verbs/— one module per subcommand (clapArgs+run).client.rs— the Forgejo client wrapper + token loading.notify.rs— the read-before-comment guard, backed by forge's own notification read-state (no local mirror to drift).body.rs— shared--body/--body-file/stdin resolution.
Full verb reference: docs/tools/forge.md.