fix(docker): fail build when atlas download stalls instead of hanging#38
Open
tabedzki wants to merge 2 commits into
Open
fix(docker): fail build when atlas download stalls instead of hanging#38tabedzki wants to merge 2 commits into
tabedzki wants to merge 2 commits into
Conversation
The build-time atlas pre-download hit the GIN server directly and would hang indefinitely when the server stalled mid-transfer, since check_latest=False only skips the version check, not the data download. Bound the download with `timeout` (ATLAS_FETCH_TIMEOUT, default 1200s) so a stalled GIN server fails the build instead of hanging it, and let download failures propagate so we never ship an image without atlases. Extract the fetch logic into fetch_atlases.py, shared by the build and by a startup re-verification in entrypoint.sh (a no-op in the normal case, but re-fetches if a runtime volume mount shadows ~/.brainglobe/). Assisted-by: ClaudeCode:claude-opus-4.8
…nced `uv run` syncs the environment with the default dependency groups (including dev) before executing. Since the image is built with `uv sync --no-dev`, the entrypoint's `uv run` calls were re-installing dev-only packages (sphinx, babel, ...) into the container at every startup. Pass --no-dev to match the build so startup neither re-syncs nor pulls dev dependencies. Assisted-by: ClaudeCode:claude-opus-4.8
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 AI text below 🤖
Problem
The Docker build pre-downloads the mouse/rat atlases from the GIN server so the app starts instantly. When GIN stalls mid-transfer,
docker buildhangs indefinitely —check_latest=Falseonly skips the remote version check, not the actual data download, and the download socket has no timeout.Change
Keep the requirement that atlases are baked into the image, but make a bad GIN server a bounded failure rather than an infinite hang:
timeout "${ATLAS_FETCH_TIMEOUT}" python /fetch_atlases.py(default 1200s) with no|| true. A stall trips the timeout and fails the build; a download error propagates and fails the build. Either way, we never ship an image without atlases.fetch_atlases.py(new) — idempotent fetch of the required atlases (skips ones already cached), non-zero exit if any is still missing. Shared by build and startup.entrypoint.sh— runs the same script at startup as a cheap safety net. It's a no-op in the normal case (atlases baked in) and only re-fetches if a runtime volume mount shadows~/.brainglobe/.REQUIRE_ATLASES=1(default) makes a missing atlas a hard startup failure; set0to warn and boot anyway.Verification
docker build -t pixelmap:build-test .succeeds; both atlases download during the build (allen_mouse_25um ~99 MB, whs_sd_rat_39um ~222 MB)./fetch_atlases.pyinside the built image reports both atlases already cached and exits 0 (startup check is a no-op as intended).🤖 Generated with Claude Code
https://claude.ai/code/session_01EQUz7NQenGjdZVVRbk3a2Y