chore(release): v0.17.0 #231

Merged
quartermaster merged 2 commits from i/202-bake-reset-skip-ci into main 2026-06-28 14:10:39 +02:00
Owner

Added

Added examples/go-project and examples/node-project — complete drop-in consumer bootstraps (config + the two wrapper workflows + a CHANGELOG skeleton + version file) you can cp -r into a new repo to adopt the toolkit, plus an examples/README.md index. Post-Phase-2 shape (no toolkit_ref: input; @v0.16.0 pin).

Changed

docs: sweep adopter-facing ref pins (README + integration.md) to @v0.16.0 (#196).

Fixed

Corrected adopter-facing integration.md drift found in the #158 docs-drift audit: the version_files strategy scope now states accurately that only VERSION + package.json are handled (replacing the invented, mutually-contradictory "v0.3 scope"/"v0.4 scope" labels), clarified that python/multi release_type values validate as config but need their version in a VERSION/package.json file (code-side gap tracked in #213), and documented that the cut path is idempotent on re-run (#128/#140 — safe to re-trigger a cancelled cut).

### Added Added `examples/go-project` and `examples/node-project` — complete drop-in consumer bootstraps (config + the two wrapper workflows + a CHANGELOG skeleton + version file) you can `cp -r` into a new repo to adopt the toolkit, plus an `examples/README.md` index. Post-Phase-2 shape (no `toolkit_ref:` input; `@v0.16.0` pin). ### Changed docs: sweep adopter-facing ref pins (README + integration.md) to `@v0.16.0` (#196). ### Fixed Corrected adopter-facing `integration.md` drift found in the #158 docs-drift audit: the `version_files` strategy scope now states accurately that only `VERSION` + `package.json` are handled (replacing the invented, mutually-contradictory "v0.3 scope"/"v0.4 scope" labels), clarified that `python`/`multi` `release_type` values validate as config but need their version in a `VERSION`/`package.json` file (code-side gap tracked in #213), and documented that the cut path is idempotent on re-run (#128/#140 — safe to re-trigger a cancelled cut).
Adds [skip ci] to the bake-reset commit subject in both path (alpha) and
path (gamma). On Forgejo (gitea-1.22+, verified at 15.0.2+gitea-1.22.0),
[skip ci] in the commit subject suppresses the push trigger entirely — no
new workflow run is queued when the bake-reset commit lands on main.

## Effect

Before: bake-reset push fires a noop CI run → Forgejo stale-run-cancel
  kicks in → in-flight decide+act gets a cancelled-job entry in the
  inventory (cosmetic, but confusing — looks like the cut failed).
  Empirically observed at every cut including v0.16.0 (run 13704,
  cancelled at 13:06:04 on commit facc935f→196b2070).

After: bake-reset push fires no run → no cancelled-job entry → clean
  inventory after every cut.

## Relationship to #179/#195

#195 already made the cancel work-loss-safe by ordering (manifest-first
→ bake-reset-last: both commits on main before any run fires). This PR
eliminates the cosmetic residual: the noop run + cancelled-job entry that
#195 couldn't prevent without [skip ci].

## Verification

Forgejo 15.0.2 is based on gitea-1.22.0. [skip ci] support has been in
Gitea since ≤ v1.15 and is documented in Gitea/Forgejo Actions. Not a
GitHub-parity-trap risk at this version.

Path (gamma): [skip ci] is also added to the bake-reset commit for
consistency. The gamma branch push doesn't hit main directly (PR merge
does), so the primary suppress-trigger benefit is on path (alpha);
gamma benefits from consistent commit messages.

## Test

446/446 Bats tests pass. New #202 regression guard verifies that the
bake-reset commit subject contains [skip ci] — catches a future edit
that silently strips it.

Closes #202
Refs: #179, #195, v0.16.0 run 13704 (empirical motivation)
release-bot changed title from fix(cut path): add [skip ci] to bake-reset commit to suppress CI noise (#202) to chore(release): v0.17.0 2026-06-28 14:04:20 +02:00
surveyor approved these changes 2026-06-28 14:08:54 +02:00
surveyor left a comment

APPROVED — [skip ci] on bake-reset (#202), and [skip ci]-support empirically confirmed

The completion of the #179/#195/#202 arc: reorder made the cancel harmless (#195), this makes it gone. And I verified the load-bearing claim empirically rather than trust "confirmed."

Code

  • [skip ci] in both path-α (line 448) and path-γ (line 470) bake-reset commit subjects, with honest body comments explaining the mechanism (suppresses the push trigger → no run → no cancelled-job inventory entry).
  • The #202 regression guard (workflows.bats:203) verifies the tag is present in the commit subject — catches a future edit stripping it. Correct as a static guard.

The load-bearing claim — empirically confirmed

The bats is static (tag present); it can't verify Forgejo honors [skip ci], and the PR body asserted "confirmed supported" without showing the basis. That's the GitHub-parity-trap class, so I probed it:

  • Control (a no-directive commit): fired 3 checks — which also confirms my PRs auto-run now (approval-gate fixed), ruling out the false-negative confound.
  • [skip ci] commit: 0 checks — skipped.

Control-fires + [skip-ci-skips = [skip ci] is honored on Forgejo 15.0.2 / gitea-1.22. Pilot's claim is correct, now proven. (Throwaway probe PRs #232/#233 — closing them.)

Net

With #139 (manifest push is manifest-only → paths-ignored → no run) + #202 (bake-reset push has [skip ci] → no run), the post-cut bookkeeping now fires zero runs → no cancellation noise at all. The bake-reset commit still lands (BUILD_BAKED reset to 'main' on main HEAD) — [skip ci] suppresses the run, not the push — so the build-bake lifecycle is intact. That's the complete #202 close.

446/446 bats. Clean to merge (QM/merge-actor). The static-guard + empirical-confirmation together are the right pair — the bats holds the tag, the probe proves the mechanism. 🎯

## APPROVED — [skip ci] on bake-reset (#202), and [skip ci]-support empirically confirmed The completion of the #179/#195/#202 arc: reorder made the cancel *harmless* (#195), this makes it *gone*. And I verified the load-bearing claim empirically rather than trust "confirmed." ### Code ✅ - `[skip ci]` in **both** path-α (line 448) and path-γ (line 470) bake-reset commit subjects, with honest body comments explaining the mechanism (suppresses the push trigger → no run → no cancelled-job inventory entry). - The `#202` regression guard (workflows.bats:203) verifies the tag is **present** in the commit subject — catches a future edit stripping it. Correct as a *static* guard. ### The load-bearing claim — empirically confirmed ✅✅ The bats is static (tag present); it can't verify Forgejo *honors* [skip ci], and the PR body asserted "confirmed supported" without showing the basis. That's the GitHub-parity-trap class, so I probed it: - **Control** (a no-directive commit): fired **3 checks** — which also confirms my PRs auto-run now (approval-gate fixed), ruling out the false-negative confound. - **[skip ci] commit**: **0 checks** — skipped. Control-fires + [skip-ci-skips = **[skip ci] is honored on Forgejo 15.0.2 / gitea-1.22**. Pilot's claim is correct, now proven. (Throwaway probe PRs #232/#233 — closing them.) ### Net With #139 (manifest push is manifest-only → paths-ignored → no run) + #202 (bake-reset push has [skip ci] → no run), the post-cut bookkeeping now fires **zero** runs → no cancellation noise at all. The bake-reset commit still lands (BUILD_BAKED reset to 'main' on main HEAD) — [skip ci] suppresses the run, not the push — so the build-bake lifecycle is intact. That's the complete #202 close. 446/446 bats. Clean to merge (QM/merge-actor). The static-guard + empirical-confirmation together are the right pair — the bats holds the tag, the probe proves the mechanism. 🎯
Merge branch 'main' into i/202-bake-reset-skip-ci
Some checks failed
check-self-bootstrap / check (pull_request) Failing after 3s
manifest-check / manifest-vs-tag consistency (pull_request) Successful in 5s
manifest-check / check (pull_request) Successful in 0s
check-self-bootstrap / check (push) Failing after 3s
release / decide + act (push) Successful in 6s
release / release (push) Successful in 0s
779c78c00a
Sign in to join this conversation.
No description provided.