fix: deploy build silently served a stale Docker layer for musehub/pyproject.toml
Found live while fixing a stale RC4 getting-started docs page: production's deployed container was still reporting musehub version 0.2.1rc4 three commits (and two successful deploys) after a version bump to 0.2.1rc5 whose only change was that one line in pyproject.toml. Every .py file change in between had correctly busted the layer cache -- confirmed the underlying fixes (schema gate, reclaim, supersede-retry) were genuinely live and working. Only the version string itself was stuck, serving from a stale cached COPY layer.
Reproduced and confirmed root cause: a clean, fully uncached rebuild of the exact same source immediately produced the correct 0.2.1rc5 content -- a real BuildKit cache-key bug on this specific COPY instruction, not a build-context or source problem.
Fix: skip the Docker build cache for the runtime stage specifically, so the cheap runtime stage (plain file COPYs, no compilation) always rebuilds fresh, while the expensive builder stage (wheel builds, cryptography compiled from source) keeps its cache -- preserves build speed where it matters, eliminates the exact class of bug where it doesn't.
Semantic Changes
Files Changed
~1
1085 in snapshot
0 comments
muse hub commit comment sha256:47c92210e23600ae975e8943d129f6c752fb4d5835fd19b8d74fbc8489ec83f8 --body "your comment"
No comments yet. Be the first to start the discussion.