fix(cut path): eliminate cancelled-job noise entry after bake-reset push (#179 residual) #202

New issue

Closed

opened 2026-06-27 15:37:53 +02:00 by claude · 0 comments

claude commented

2026-06-27 15:37:53 +02:00

Owner

Background

#195 split the post-cut bake-reset from the manifest commit and reversed the push order (manifest-first → bake-reset-last) so the stale-run-cancel that fires on the bake-reset push is harmless — both commits are already on main by then. #179 is closed as "made harmless."

Residual

The stale-run-cancel noise entry persists: every cut still produces one cancelled-job entry in the CI inventory (the in-flight decide+act run gets cancelled when the bake-reset push fires a new run). The cancel is harmless (no work lost), but the cancelled-job row in the UI is confusing — it looks like the cut failed.

Empirically confirmed at v0.16.0 (2026-06-28 13:06:04): run 13704 cancelled on commit facc935f→196b2070.

Options

(A) `[skip ci]` on the bake-reset commit ← implemented in #231

Add [skip ci] to the bake-reset commit message subject. Forgejo/Gitea honors this to suppress the push trigger → no new run fired → no stale-run-cancel → no cancelled-job entry.

Forgejo 15.0.2 = gitea-1.22.0, which fully supports [skip ci]. Not a GitHub-parity-trap risk at this version.

(B) At-re-pin bake-reset (option B from #179 body)

Move the bake-reset to the re-pin commit instead of the post-cut commit. No extra push at all.

Pros: zero extra runs, no cancelled-job noise, no CI directive in commit
Cons: bounded poison window between cut and re-pin (consumers on @main see stale bake value during window — rare/bounded)

Refs

#179 (the parent issue; this is the residual)
#195 (the PR that made the cancel harmless by ordering)
#231 (the PR implementing option A)
Surveyor 4a3b (scoping note that drove this follow-up)
Surveyor 13a8 (original [skip ci] / at-re-pin option tree)
v0.16.0 run 13704 (empirical motivation)

## Background #195 split the post-cut bake-reset from the manifest commit and reversed the push order (manifest-first → bake-reset-last) so the stale-run-cancel that fires on the bake-reset push is **harmless** — both commits are already on main by then. #179 is closed as "made harmless." ## Residual The stale-run-cancel **noise entry** persists: every cut still produces one cancelled-job entry in the CI inventory (the in-flight decide+act run gets cancelled when the bake-reset push fires a new run). The cancel is harmless (no work lost), but the cancelled-job row in the UI is confusing — it looks like the cut failed. Empirically confirmed at v0.16.0 (2026-06-28 13:06:04): run 13704 cancelled on commit facc935f→196b2070. ## Options ### (A) `[skip ci]` on the bake-reset commit ← **implemented in #231** Add `[skip ci]` to the bake-reset commit message subject. Forgejo/Gitea honors this to suppress the push trigger → no new run fired → no stale-run-cancel → no cancelled-job entry. Forgejo 15.0.2 = gitea-1.22.0, which fully supports `[skip ci]`. Not a GitHub-parity-trap risk at this version. ### (B) At-re-pin bake-reset (option B from #179 body) Move the bake-reset to the re-pin commit instead of the post-cut commit. No extra push at all. **Pros**: zero extra runs, no cancelled-job noise, no CI directive in commit **Cons**: bounded poison window between cut and re-pin (consumers on `@main` see stale bake value during window — rare/bounded) ## Refs - #179 (the parent issue; this is the residual) - #195 (the PR that made the cancel harmless by ordering) - #231 (the PR implementing option A) - Surveyor 4a3b (scoping note that drove this follow-up) - Surveyor 13a8 (original [skip ci] / at-re-pin option tree) - v0.16.0 run 13704 (empirical motivation)

claude referenced this issue

2026-06-27 15:38:09 +02:00

fix(cut path): split bake-reset from manifest commit (#179) #195