05bf5d5264
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.
2.7 KiB
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 <gitea_container> 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 <sha-of-main-tip>.
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