hive-forge: ci-rerun --pr refuses instead of lying about a fix it can't achieve

A workflow_dispatch run writes no commit status, so ci-rerun --pr could
never clear the red (pull_request) check it claimed to be re-running for
- it dispatched a fresh run and printed a success message regardless,
even though the check stays red no matter how that run turns out.

--pr now refuses up front, before dispatching, naming the mechanism and
the working alternative (re-run from the web UI). --run and --branch are
unchanged: --run's own PR-pseudo-ref resolution and --branch's direct
dispatch are both untouched.

Fixes the exit-code/honesty defect from #4613; the workflow_dispatch vs.
pull_request event-type question (whether to close+reopen the PR to fire
a real pull_request event) is a separate, parked decision.
This commit is contained in:
atlas 2026-09-21 20:27:46 +02:00 committed by mara
commit 92100ac1f8
2 changed files with 52 additions and 19 deletions

View file

@ -103,7 +103,7 @@ hive-forge attach-comment 18042 /path/to/file # upload a file attachment to a c
hive-forge attachment-get <uuid> # download an attachment; prints resolved path to stdout
hive-forge artifact-get pr1ma-paper-pdf --run 51 # download a CI run's Actions artifact zip (run number from the run-page URL)
hive-forge ci-log --run 51 # print a CI run's job step logs (run number from the run-page URL); --job i / --step i to narrow
hive-forge ci-rerun --pr 42 # re-run CI without an empty commit (dispatches a fresh run; --run n / --branch name also work)
hive-forge ci-rerun --branch foo # re-run CI without an empty commit (dispatches a fresh run; --run n also works; --pr refuses, see below)
hive-forge subscription --watch # subscribe to repo notifications
hive-forge subscription --unwatch # unsubscribe
hive-forge subscription --list # list every repo you watch (audit the notification firehose)
@ -293,12 +293,14 @@ to discover valid label names before triaging or to audit the label set.
are CSRF-gated web routes a token POST 404s), so this dispatches a
**fresh** run of the workflow via the workflow-dispatch API
(`POST …/actions/workflows/<workflow>/dispatches {"ref":"<branch>"}`).
Resolve the branch with exactly one of: `--pr <n>` (the PR's head
branch), `--run <n>` (the same run number `ci-log` / `artifact-get`
take — resolves the branch + workflow from that run), or `--branch
<name>` (directly). `--workflow <file>` picks the workflow file for
`--pr` / `--branch` (default `ci.yml`). Dispatch re-runs the whole
workflow — there is no single-job variant.
Resolve the branch with `--run <n>` (the same run number `ci-log` /
`artifact-get` take — resolves the branch + workflow from that run) or
`--branch <name>` (directly). `--pr <n>` refuses instead of dispatching:
a workflow-dispatch run writes no commit status, so it can't clear a
red `(pull_request)` check on that PR's sha — re-run from the web UI
instead. `--workflow <file>` picks the workflow file for `--branch`
(default `ci.yml`). Dispatch re-runs the whole workflow — there is no
single-job variant.
- `issue dependency <n> add <dep...>` / `pr dependency <n> add <dep...>`
set "blocked by" links via Forgejo's dependency feature — the
operator's preferred way to track blocking relationships over labels