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): drop the factually wrong 'a new commit doesn't reliably work either' clause

Browse source
This commit is contained in:
damocles 2026-08-24 14:44:53 +02:00 • committed by mara
commit 8f53c223c1
1 changed files with 4 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

11
docs/ci.md
View file

@ -56,15 +56,12 @@ 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 that's the only thing that reliably moves 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
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, and it doesn't even work reliably for the same reason `ci-rerun`
doesn't (a brand-new commit's own `pull_request` run is genuine, but
convincing yourself the diff needed a commit it didn't is the actual
problem).** If the code is verified green — read the dispatched run's own
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