chore(release): adopt rivet 0.22 release-handling — migrate v0.1.0 scope tag→field + burn-down#123
Merged
Merged
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
…ope tag→field + burn-down rivet 0.21/0.22 shipped release-handling (#516) — the first-class `release:` field + `rivet release status <ver>` readiness burn-down (exits non-zero when not cuttable, CI-gateable) + `rivet list --release` + `rivet release move`. This is the feature that resolved gale's earlier request (pulseengine/rivet#512), where we'd used a `release-vX.Y.Z` TAG as the workaround. Adopt it on gale's existing release plan (v0.1.0 = semaphore, depth-first): - **Migrate the v0.1.0 scope** from the `release-v0.1.0` tag to the native `release: v0.1.0` field on the 11 semaphore artifacts (SYSREQ-SEM-001 + SWREQ-SEM-P01..P10). `rivet release status v0.1.0` now renders the burn-down: 11 artifacts, all `approved`, NOT cuttable (exit 1) — matching the documented plan (the sem V isn't closed yet: verifications authored but not yet linked). - **Bump compliance.yml**: rivet-version v0.15.0 → v0.22.0 and the compliance action v0.19.0 → v0.22.0. `rivet validate` = PASS on gale's 967 artifacts under 0.22 (45 pre-existing coverage warnings, 0 errors). - **Add the burn-down step** to compliance.yml: `rivet release status <tag>` into the job summary at release time (advisory — see below). - **Update docs/release-plan.md** to the native `release:` field + `rivet release status` (off the tag-based query). KNOWN LIMITATION (filed pulseengine/rivet#612): `release status` judges cuttability by `status ∈ {verified,accepted}` only, but gale (ASPICE V-model) marks artifacts verified via `verified-by`/`verified-on` LINKS (what `rivet validate` coverage checks), with terminal req status `approved`. So the burn-down VERDICT always reads "not cuttable" for gale; the COUNTS are accurate. Hence the burn-down is advisory (non-blocking) and the real V-gate stays `rivet validate` — until #612 lands, when it flips to a hard gate. Oracle: rivet 0.22 `validate` = PASS; `release status v0.1.0` = 11 sem artifacts, exit 1 (gate works); compliance.yml valid YAML; gust_driver_model.yaml unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
avrabe
force-pushed
the
chore/adopt-rivet-0.22-release-handling
branch
from
3c2e5a6 to
f887758
Compare
avrabe
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
rivet 0.21/0.22 shipped release-handling (#516) — first-class
release:field +rivet release status <ver>readiness burn-down (CI-gateable, exit non-zero when not cuttable) +rivet list --release+rivet release move. This is the feature that resolved gale's earlier request (pulseengine/rivet#512), where we used arelease-vX.Y.Ztag as the workaround. This PR adopts it on gale's existing release plan (v0.1.0 = semaphore) and tests it end-to-end.release-v0.1.0tag to the nativerelease: v0.1.0field on the 11 semaphore artifacts (SYSREQ-SEM-001+SWREQ-SEM-P01..P10). Tested:rivet release status v0.1.0→ 11 artifacts, allapproved, NOT cuttable, exit 1 ✓ (matches the documented plan — sem V not yet closed)rivet list --release v0.1.0→ 11 artifacts ✓rivet release move … v0.1.1→ logged scope change, round-trips,validatestays PASS ✓compliance.yml: rivet-version v0.15.0 → v0.22.0, action v0.19.0 → v0.22.0.rivet validate= PASS on gale's 967 artifacts under 0.22 (45 pre-existing coverage warnings, 0 errors).compliance.yml(rivet release status <tag>→ job summary at release time).docs/release-plan.mdto the native field +rivet release status(off the tag query).Known limitation — filed pulseengine/rivet#612
release statusjudges cuttability bystatus ∈ {verified, accepted}only, but gale (ASPICE V-model) marks artifacts verified viaverified-by/verified-onlinks (whatrivet validatecoverage checks), with terminal req statusapproved. So the burn-down verdict always reads "not cuttable" for gale; the counts are accurate. The burn-down step is therefore advisory, and the real V-gate staysrivet validate— flipping to a hard gate once #612 lands.Oracle
validate= PASS (0 errors)rivet release status v0.1.0= 11 sem artifacts, exit 1 (gate behavior confirmed)compliance.ymlvalid YAML;gust_driver_model.yamlunchanged vs main🤖 Generated with Claude Code