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
BURNIN.md
+8 -5
View File
@@ -10,7 +10,7 @@ implementation work.
## Burn-in build identity
`86b67d9fbff459fe5ae3415cc59594e26cc665f3`
`6f9300b549362c4c5788f8845b56aaff9672d993`
Both halves must report exactly this revision before a task is created. Neither
needs a credential now: the coordinator prints it in `docker logs orchestra-api`
@@ -18,21 +18,24 @@ and the worker in `journalctl -u orchestra-worker`. The same object is at
`GET /v1/admin/diagnostics` and `GET /v1/federation/workers` behind the operator
login.
Build both with `deploy/build.sh <outdir>`, which refuses a dirty tree.
Build both with `deploy/build.sh <outdir>`, which refuses a dirty tree. Later
documentation-only commits do not change this identity, so a rebuild either
passes this revision explicitly or accepts the new one and redeploys both
halves. Never one half.
## Deployment state, 2026-08-26 18:35
| Half | State |
|---|---|
| Coordinator (homesrv) | **Deployed at 86b67d9.** Rebuilt with `--build-arg BUILD_REVISION`, recreated, `/readyz` ready, self-reporting the revision in its log |
| Worker (workpc) | **Staged, not installed.** `~/orchestra-deploy/orchestra-worker` sha256 `140035811bf22f6c2ae25f0130c80095eea272fe8fed7987312ccee6f418e2a7`. Installed binary is still the 2026-07-30 build |
| Coordinator (homesrv) | **Deployed at 6f9300b.** Rebuilt with `--build-arg BUILD_REVISION`, recreated, `/readyz` ready, self-reporting the revision in its log |
| Worker (workpc) | **Staged, not installed.** `~/orchestra-deploy/orchestra-worker` sha256 `2b1c43071eaf6b5c15b110de39f204038a9629897e0ce3dacf45be96a6e6529e`. Installed binary is still the 2026-07-30 build |
Two operator steps remain, both needing root:
```sh
sudo install -m 0755 /home/kami/orchestra-deploy/orchestra-worker /usr/local/bin/orchestra-worker
sudo systemctl restart orchestra-worker
journalctl -u orchestra-worker -n 5 --no-pager # must print revision 86b67d9...
journalctl -u orchestra-worker -n 5 --no-pager # must print revision 6f9300b...
```
Then scrub the pane environment before letting an agent run.