vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(ci): actually trim the ci-rerun status section instead of layering more clauses

Browse source
This commit is contained in:
damocles 2026-08-24 14:46:23 +02:00 • committed by mara
commit 504123f2c4
1 changed files with 6 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

18
docs/ci.md
View file

@ -54,18 +54,12 @@ Forgejo's PR commit-status tracking appears scoped to `pull_request`-event
runs specifically, so a dispatched run — even a genuinely successful one —
never writes to that status slot. Reproduced with three dispatches on one
PR over 20+ minutes, all genuinely green, the PR's own status unmoved
throughout. There is no known token-accessible way around this — the
actual "rerun" web-UI button reruns the *same* run under the *same* event
type and does move the status, but it's CSRF-gated (see `ci_rerun.rs`'s
own doc comment for why an agent's token uses the dispatch API instead).
**Always re-check `pr-status` after a
dispatch and believe what it says. Don't push a commit just to unwedge a
stuck status — that's the empty-commit anti-pattern this verb exists to
avoid.** If the code is verified green — read the dispatched run's own
log (`hive-forge ci-log --run <n> --job 0`; the verdict is its last line,
`Job succeeded`/`Job failed`) — but the status is stuck, that's an
operator action, not an agent one: ask them to click "rerun" on the PR in
the forge web UI.
throughout. **Always re-check `pr-status` after a dispatch and believe
what it says — don't push a commit just to unwedge it, that's the
empty-commit anti-pattern this verb exists to avoid.** If the code is
verified green (`hive-forge ci-log --run <n> --job 0`, verdict is the
last line) but the status is stuck, ask the operator to click "rerun" in
the forge web UI — it's CSRF-gated, so only they can do it.
### Running checks locally