fix(selfhost): block deploy-selfhost-prebuilt on container health, sharing wait_for_healthy#8444
Conversation
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
…aring wait_for_healthy (JSONbored#8395)
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #8444 +/- ##
=======================================
Coverage 92.42% 92.43%
=======================================
Files 791 791
Lines 79294 79318 +24
Branches 23952 23954 +2
=======================================
+ Hits 73291 73315 +24
Misses 4866 4866
Partials 1137 1137
Flags with carried forward coverage won't be shown. Click here to find out more. |
|
Tip ✅ LoopOver review result - approve/merge recommendedReview updated: 2026-07-24 13:59:32 UTC
Review summary Nits — 4 non-blocking
Decision drivers
Context & advisory signals — never blocks the verdict
Linked issue satisfactionAddressed Review context
Contributor next steps
Signal definitions
🧪 Chat with LoopOverAsk LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.
Full command reference: https://loopover.ai/docs/loopover-commands 🧪 Experimental — new and may change. 🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed 💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →. Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.
|
Summary
deploy-selfhost-prebuilt.shprintedselfhost deploy: completeimmediately afterdocker compose up -d, which only confirms the container was created and started — a freshly built image that crash-loops or never passes its health check still reported success. Its siblingdeploy-selfhost-image.shhas always blocked on real health viawait_for_healthy. Both are documented standalone entry points, so an operator running the prebuilt script directly (its own documented usage) got a false success signal.wait_for_healthymoves fromdeploy-selfhost-image.shintoscripts/lib/selfhost-deploy-common.sh, joining the helpers both deploy scripts already share (require_cmd,env_get/env_put,maybe_infisical_run,compose_file_args).wait_for_healthy <service> <timeout_seconds> <log_prefix> <compose_args...>. This is required, not stylistic:compose_argsis a function-local array in the prebuilt script (it includes the generated override file), so the old global-reading form could not be shared.deploy-selfhost-image.shcalls the shared version with its existing values, andlog_prefixkeeps its success line byte-identical (selfhost image deploy: <service> is healthy) — no behavior change there.deploy-selfhost-prebuilt.shcalls it at the end ofrun_compose_deploy(wherecompose_argsis in scope) and gainsHEALTH_TIMEOUT_SECONDS="${SELFHOST_HEALTH_TIMEOUT_SECONDS:-180}", the same override and default the image script already honours. On timeout it exits non-zero with the identicaldocker compose ps/logs --tail=80diagnostics; the script's existingEXITtrap still removes the temp override file on that path.docker-compose.yml's healthcheck,selfhost-post-update-check.sh, andselfhost-update.share untouched, per the issue's scope.Closes #8395
Test plan
No Docker daemon in CI and
scripts/**is outside Codecov'scoverage.include, so this was verified directly:bash -nclean on all three changed scriptsdocker: the healthy path prints<prefix>: <service> is healthyand returns 0 (does not exit, so the image script's subsequentenv_put/completion lines still run); the timeout path exits 1 and writeserror: <service> did not become healthy within <N>sto stderrlog_prefixparameter reproducesdeploy-selfhost-image.sh's original message exactly, so its output is unchanged