ci(windows update): use jq instead of windows-python to read health.json

The "Boot Studio briefly to confirm the install is still usable" step
writes /api/health to /tmp/health.json from MSYS Git Bash and reads it
back with `python -c "json.load(open('/tmp/health.json'))"`. Git Bash
on windows-latest resolves /tmp against the MSYS root, while the
setup-python interpreter is Windows-native and resolves /tmp against
the current drive's root. The two paths don't agree, so python's
open(...) fails with FileNotFoundError even though curl just wrote
the file.

Switch to `jq -e '.status == "healthy"' /tmp/health.json`. jq is a
Git Bash builtin so it reads through the same MSYS path and finds
the file. Mirrors studio-windows-api-smoke.yml,
studio-windows-ui-smoke.yml, and
studio-windows-inference-smoke.yml.

Failure surfaced once the upstream "unsloth studio update" step
started actually emitting output to update.log (run 25534895087 /
job 74948624523).
This commit is contained in:
Daniel Han 2026-05-08 04:51:09 +00:00
commit e46860b4d0

View file

@ -183,9 +183,19 @@ jobs:
> logs/studio.log 2>&1 &
PID=$!
HEALTHY=""
# Use jq (a Git Bash builtin) instead of `python -c
# open('/tmp/health.json')` to read the saved health
# response. Bash on windows-latest is MSYS Git Bash, which
# resolves `/tmp/...` against the MSYS root, while the
# python interpreter is Windows-native and resolves it
# against the current drive's root. The two paths don't
# agree, so python never finds the file curl just wrote.
# jq reads through MSYS, so the path matches. Mirrors what
# studio-windows-api-smoke.yml and the other Windows smoke
# workflows already do.
for i in $(seq 1 60); do
if curl -fs http://127.0.0.1:18891/api/health > /tmp/health.json; then
if python -c "import json,sys; d=json.load(open('/tmp/health.json')); sys.exit(0 if d.get('status')=='healthy' else 1)"; then
if jq -e '.status == "healthy"' /tmp/health.json >/dev/null; then
HEALTHY=1
break
fi