smoke: wait for pi-extensions deploy completion, not just keybindings
Validate / base-change-warning (push) Successful in 6s
Validate / docs-check (push) Successful in 11s
Validate / validate-base (push) Successful in 3m24s
Validate / validate-with-pi (push) Successful in 4m59s
Validate / validate-omos (push) Successful in 6m59s
Validate / validate-pi-only (push) Successful in 4m20s
Validate / validate-omos-with-pi (push) Successful in 14m33s

The entrypoint-deploy wait loop gated only on keybindings.json (written by
pi-toolkit, before pi-extensions), so the *.ts >= 4 assertion could sample
mid-deploy under parallel build load. v1.16.2 run 370: smoke-with-pi saw <4
while omos-with-pi/pi-only (same pi-extensions 357fcc6) saw 8, skipping
build-variant-with-pi. Now wait for the last-deployed artifact (mempalace.ts
bridge) AND a settled extension count (>=4), up to 45s. Test-only; no image
change, so no re-tag needed.
This commit is contained in:
pi
2026-06-08 22:49:09 +02:00
parent 56e6a782e3
commit c6f9d1148b
2 changed files with 28 additions and 5 deletions
+13 -1
View File
@@ -8,7 +8,19 @@ Tags follow `v{opencode_version}[letter]` — bare tag for the first build on a
## Unreleased ## Unreleased
_(no changes since v1.16.2)_ ### Fixed: smoke-test pi-extensions readiness race (test-only, no image change)
`scripts/smoke-test.sh`'s entrypoint-deploy wait loop gated only on
`keybindings.json` (written by pi-toolkit, which runs *before* pi-extensions),
so the `~/.pi/agent/extensions/*.ts ≥ 4` assertion could sample mid-deploy and
see fewer than 4 files under parallel build load. Observed on v1.16.2 run 370:
`smoke-with-pi` saw `<4` while `smoke-omos-with-pi` / `smoke-pi-only` (identical
pi-extensions `357fcc6`) both saw 8, skipping `build-variant-with-pi`. The wait
loop now blocks until the *last*-deployed artifact (the `mempalace.ts` bridge
symlink) exists **and** the extension count has settled ≥ 4 (up to 45s). Affects
only when smoke samples the container — image bytes are unchanged, so this does
not warrant a new tag; it lands in the next release and is exercised by
`validate.yml` on this push.
## v1.16.2 — 2026-06-08 ## v1.16.2 — 2026-06-08
+15 -4
View File
@@ -200,10 +200,21 @@ if docker run --rm --entrypoint="" "$IMAGE" sh -c "command -v pi" >/dev/null 2>&
trap 'docker rm -f "$CID" >/dev/null 2>&1 || true' EXIT trap 'docker rm -f "$CID" >/dev/null 2>&1 || true' EXIT
# Wait for entrypoint-user.sh to finish deploying pi-toolkit + extensions. # Wait for entrypoint-user.sh to finish deploying pi-toolkit + extensions.
# Marker: keybindings.json symlink lands once pi-toolkit/install.sh has run. # The deploy order is: pi-toolkit (writes keybindings.json) -> pi-extensions
# Up to 30s — omos-with-pi has more setup work than base+pi. # (symlinks its *.ts) -> settings.json -> mempalace.ts bridge (LAST). Gating
for _ in $(seq 1 30); do # only on keybindings.json races: it lands when pi-toolkit finishes, before
if docker exec "$CID" test -L /home/developer/.pi/agent/keybindings.json 2>/dev/null; then # pi-extensions has symlinked its *.ts, so the "*.ts >= 4" check below could
# sample mid-deploy under parallel build load (observed v1.16.2 run 370:
# smoke-with-pi saw <4 .ts while omos-with-pi/pi-only saw 8). Wait for the
# LAST-deployed artifact (the mempalace.ts bridge symlink) AND a settled
# extension count so the deploy is fully complete before any assertion runs.
# Up to 45s — pi-bearing variants have more setup work under load.
for _ in $(seq 1 45); do
if docker exec "$CID" sh -c \
'test -L $HOME/.pi/agent/keybindings.json && \
test -L $HOME/.pi/agent/extensions/mempalace.ts && \
[ "$(ls -1 $HOME/.pi/agent/extensions/*.ts 2>/dev/null | wc -l)" -ge 4 ]' \
2>/dev/null; then
break break
fi fi
sleep 1 sleep 1