From 69f630a5f1a5eb63c72ca2e059402ef02c97a7a0 Mon Sep 17 00:00:00 2001 From: kami Date: Wed, 26 Aug 2026 18:36:53 +0400 Subject: [PATCH] Point the burn-in identity at HEAD Co-Authored-By: Claude Opus 5 --- AUDIT.md | 11 +++++++---- BURNIN.md | 13 ++++++++----- 2 files changed, 15 insertions(+), 9 deletions(-) diff --git a/AUDIT.md b/AUDIT.md index 4881e9c..c9146f8 100644 --- a/AUDIT.md +++ b/AUDIT.md @@ -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 diff --git a/BURNIN.md b/BURNIN.md index 1e9502e..455e607 100644 --- a/BURNIN.md +++ b/BURNIN.md @@ -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 `, which refuses a dirty tree. +Build both with `deploy/build.sh `, 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.