kami/orchestra
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Point the burn-in identity at HEAD

Browse Source 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
kami
2026-08-26 18:36:53 +04:00
parent 6f9300b549
commit 69f630a5f1
2 changed files with 15 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AUDIT.md
+7 -4
View File
@@ -336,14 +336,17 @@ Probed live state, and the burn-in is blocked on deployment, not on code:
## Burn-in deployment, 2026-08-26 18:35
Burn-in build identity: `86b67d9fbff459fe5ae3415cc59594e26cc665f3`. The v3 stack
is committed (`7f12c7f`), followed by startup revision logging (`86b67d9`).
Burn-in build identity: `6f9300b549362c4c5788f8845b56aaff9672d993`. The v3 stack
is committed (`7f12c7f`), then startup revision logging (`86b67d9`), then this
record. Both halves are built from `6f9300b` so the identity is HEAD, and a
later `deploy/build.sh` cannot silently produce a different revision than the
one deployed.
- **Coordinator deployed.** Rebuilt on homesrv with `--build-arg
BUILD_REVISION/BUILD_TIME/BUILD_DIRTY`, container recreated, `/readyz` ready.
It now logs `orchestra revision 86b67d9... dirty false` at startup.
It now logs `orchestra revision 6f9300b... dirty false` at startup.
- **Worker staged, not installed.** `~/orchestra-deploy/orchestra-worker`,
sha256 `1400358...`. `install` and `systemctl restart` need root, which this
sha256 `2b1c430...`. `install` and `systemctl restart` need root, which this
sandbox does not have, so the running worker is still the 2026-07-30 build.
Until it is installed the pair is mismatched and no task should be created.
- **Observability fixed before proceeding**, per the requirement that deployed