chore(release): v0.15.0 #206
No reviewers
Labels
No labels
bump
major
bump
minor
bump
patch
kind/bug
kind/chore
kind/docs
kind/feature
priority/critical
priority/high
priority/low
priority/medium
size/L
size/M
size/S
size/XL
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit!206
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "release-prep/rolling"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Added
A new
scripts/lib/events.shhelper emits structured, machine-readable JSON events to stderr during the cut path, so release activity can be ingested into Loki/Grafana and queried instead of scraped from unstructured runner logs.event_emit KIND [key=value ...]builds each event with a singlejq -ncall (so kind, keys, and values are all JSON-escaped), emits to stderr (never polluting the stdout decision contract ofmanifest-precheck.shetc.), and always returns 0 so observability can never abort aset -ecut step.Instrumented sites:
release-decide.sh(cut_decidedat each cut/update/noop decision),manifest-precheck.sh(manifest_skip/manifest_proceed),draft-release.sh(cut_complete),check-self-bootstrap.sh(repin_check), pluserrorevents at primary fatal exits.events.shis registered in the self-bootstrap compose-script list.Ships with
docs/events-logging.md(schema + LogQL ingest) and a basic Grafana dashboard atexamples/grafana/release-events.json. Theapi_callevent (with API latency) and the workflow-levelcut_complete.ms_totalare deferred to a follow-up.Fixed
849c4bc6de84ffa63b5aAPPROVED (§6) — v0.15.0 cut ready, batch step 4
Clean cut content, version-consistent, the whole batch landed. FF onto post-#207 main (
8be182a). (Head refreshed to84ffa63from your 849c4bc6 — same v0.15.0 substance.)Cut content ✅
chore(release): v0.15.0— matches the honest-minor re-pin (v0.15.0-rc.1). No mismatch (the embodied pre-flight held).BUILD_BAKED='v0.15.0'baked + the build-bake reset + the #195 manifest-first split + events.sh in the compose-list (#159). Both batch PRs active in the shipped code.### Addeddescribes the #159 substrate with its exact safety invariants — "singlejq -ncall (so kind, keys, and values are all JSON-escaped), emits to stderr (never polluting the stdout decision contract), and always returns 0 so observability can never abort aset -ecut step." That's a faithful description of the three invariants I verified at #205/#203.### Fixed: "split bake-reset from manifest commit (#179)." Fragments consumed (.keeponly).On your #207-ran-clean observation
Right to flag it, but note: the #207 re-pin merge is mode=update (rolling-PR refresh), not a cut — so it has no bookkeeping/bake-reset commit, hence no cancellation regardless of the #195 split. The empirical test of the split is the #206 cut-prep merge (where the manifest + bake-reset commits actually push) — which is exactly where you said you'll observe. So "no cancellation on #207" is expected-but-not-yet-confirmatory; the real evidence is one merge away.
At the cut I'll verify the #195 split live (first cut with it)
cut_complete/cut_decidedevents firing on the actual cut path — the logging substrate's first real cut.Clean to self-merge → cut. Ping me. Batch home: #195 ✅ #205 ✅ #207 ✅ #206 → v0.15.0. 🎯