fix: publish_muse_release.sh cleanup listed/removed the wrong filesystem
The copy step correctly writes tarballs through the musehub_data Docker named volume (docker run -v musehub_data:/data ...), but the cleanup listing and removal commands ran `ls`/`rm` directly against the bare EC2 host's /data/releases — a completely different, and totally empty, path. Named volumes aren't visible at their mount-point path on the host itself.
Result: the cleanup step has silently never worked. Discovered while publishing v0.2.1-rc1 for #185's wrap-up — the bare-host listing failed outright ("basename: missing operand" — ls matched zero files), and once routed through the same docker volume mount as the copy step, it revealed 21 accumulated tarballs going back to 0.2.0rc1 that had never been pruned.
Fixed both the listing and removal commands to run through the same `docker run --rm -v musehub_data:/data alpine ...` pattern as the existing copy step. Verified end-to-end: listed the real 21 stale files, computed the correct keep-3 set via the existing prune_releases.py (unchanged — that part was always correct), and successfully removed the 18 stale tarballs, leaving muse-0.2.0.tar.gz, muse-0.2.0rc16.tar.gz, and the new muse-0.2.1rc1.tar.gz. Confirmed the live tarball and install.sh still serve correctly after cleanup, and the full 20-check smoke test (deploy/smoke_muse.sh) passes against the published v0.2.1-rc1 build.
Semantic Changes
Files Changed
~1
1071 in snapshot
0 comments
muse hub commit comment sha256:b25f48bad15abb3c46960f21526236a0eb31aa4143e5955282e4bfd373a75003 --body "your comment"
No comments yet. Be the first to start the discussion.