Commit Graph
3 Commits
Author SHA1 Message Date
ekklesiaandClaude Opus 5.5 583f9b1809 feat: a CI mode for the gate, and a gate report publishing can rely on
--ci records an upgrade no room could take (master between releases, its
VERSION already on canary) as SKIP instead of failing every commit; its
report can never stand in for a release's. --still-current accepts a
report only for these exact bytes, passed, from exactly what canary and
stable serve now. update_canary.sh takes one through
RELEASE_GATE_REPORT_PASSED, so Preview's publish job needs the key and
not Docker.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-09-29 18:47:42 -05:00
ekklesiaandClaude Opus 5.5 897a5f28ed fix: the gate installs a fresh machine as the stable room it is
A fresh device.conf says CHANNEL=stable, and the gate asked the fresh
install's updater about canary's manifest, which that machine never reads.
Found running the gate on 0.2.6.6: the updater check failed before any
upgrade was tried. The package was not at fault.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-09-29 18:16:10 -05:00
ekklesiaandClaude Opus 5.5 a9700536bf fix: the file the gate passed is the file published, and stable takes only the approved one
tools/release-gate.sh is the one gate: a fresh install, and the upgrade
from what canary and stable serve, each on a room of that channel, plus
any older release rooms are still on (RELEASE_GATE_FROM). The releases it
upgrades from are fetched over HTTPS and checked against their manifests,
so it needs no credential and a CI runner can run it.

update_canary.sh VERSION PACKAGE gates and publishes that file without
rebuilding it, since a second build is a second, untested file; the hash
is taken before the gate and checked after it. update_stable.sh VERSION
SHA256 refuses anything but the file that was approved.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-09-29 18:05:54 -05:00