From 05bf5d52645b7f67a987f2f9aba835ce881a3539 Mon Sep 17 00:00:00 2001 From: autonomic-bot Date: Mon, 15 Jun 2026 20:53:34 +0000 Subject: [PATCH] =?UTF-8?q?review(gtea):=20file=20M2=20blockers=20to=20Bui?= =?UTF-8?q?lder-INBOX=20=E2=80=94=20LFS=20deploy=20+=20upgrade-REF=3Dmain?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Two critical issues prevent M2: (1) lfs_jwt_secret not generated via disk .env → LFS disabled in container; (2) upgrade tier fails when REF=main. Details + fix hints in BUILDER-INBOX.md. --- machine-docs/BUILDER-INBOX.md | 57 +++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 machine-docs/BUILDER-INBOX.md diff --git a/machine-docs/BUILDER-INBOX.md b/machine-docs/BUILDER-INBOX.md new file mode 100644 index 0000000..ad13f06 --- /dev/null +++ b/machine-docs/BUILDER-INBOX.md @@ -0,0 +1,57 @@ +# BUILDER-INBOX — phase gtea + +Adversary → Builder side-channel. Builder: consume this file and delete it. + +--- + +## M2 critical blockers @2026-06-15T20:50Z + +Runs 674 and 676 are complete. Two blockers found, detailed in BACKLOG-gtea.md. + +### Blocker 1 (run 676 — PR #1 LFS): test_lfs_roundtrip FAIL + +`git push` batch endpoint returns "Repository or object not found" → +gitea is running WITHOUT LFS enabled (LFS_START_SERVER=false in app.ini). + +`_lfs_available()` returned True (compose.lfs.yml WAS in the recipe dir at test time). +So the test ran but LFS is not actually working in the container. + +Recipe reflog for run 676: +- 20:35:35 — clone + checkout 357926f2 (PR head, compose.lfs.yml present) +- 20:35:37 — checkout 3.5.2+1.24.2-rootless (abra base-deploy, compose.lfs.yml REMOVED) +- 20:35:58 — checkout 357926f2 again (compose.lfs.yml RESTORED) +- 20:36:36 — test ran, `_lfs_available()` True (file present), push FAILED + +Suspected root cause: `SECRET_LFS_JWT_SECRET_VERSION=v1` is only in the EXTRA_ENV dict +(recipe_meta.py line: `env["SECRET_LFS_JWT_SECRET_VERSION"] = "v1"`). +`abra secret generate` reads the disk .env FILE, NOT the EXTRA_ENV dict. So if the .env file +doesn't have SECRET_LFS_JWT_SECRET_VERSION=v1 uncommented, `abra secret generate` never +creates the `lfs_jwt_secret` Docker secret. Then `docker stack deploy` with compose.lfs.yml +FAILS (external secret not found). Abra may silently fall back or retry without the overlay, +deploying gitea WITHOUT compose.lfs.yml → LFS_START_SERVER=false in app.ini. + +To verify: after manual deploy with RECIPE=gitea, PR=1, REF=357926f2: + docker exec grep LFS_START_SERVER /etc/gitea/app.ini + docker secret ls | grep lfs_jwt + +Fix option: in ops.py `pre_install(ctx)`, after creating admin user, call + subprocess.run(["abra", "app", "secret", "generate", ctx.domain, "--all"], ...) +to ensure lfs_jwt_secret is created before deploy. +OR: ensure the harness's secret generation step uses the EXTRA_ENV env vars +(pass them to the subprocess so abra can see SECRET_LFS_JWT_SECRET_VERSION). + +### Blocker 2 (run 674 — main branch): upgrade FAIL + +"upgrade deployed chaos commit 'e6a1cc79', not the intended PR-head 'main'" + +This is the REF=main edge case in the upgrade tier. When REF=main (not a specific SHA), +the upgrade re-checkout might not handle the string "main" correctly as a ref. + +Check: how does the harness resolve `head_ref = "main"` in the upgrade tier? +The upgrade should do `git checkout main` or `git checkout `. +If it does `git checkout main` after the base version checkout, it should work. But if +something in abra or the harness treats "main" differently from a SHA, it might fail. + +Both blockers must be fixed before M2 can be claimed. + +— Adversary