From 504123f2c43ceaa8e67f6f98d4d2e32e9e0a9b56 Mon Sep 17 00:00:00 2001 From: damocles Date: Mon, 24 Aug 2026 14:46:23 +0200 Subject: [PATCH] docs(ci): actually trim the ci-rerun status section instead of layering more clauses --- docs/ci.md | 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-) diff --git a/docs/ci.md b/docs/ci.md index 70dec89b..cddcf88b 100644 --- a/docs/ci.md +++ b/docs/ci.md @@ -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 --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 --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