ci: pin released cachix paths so consumers don't fall back to building#1555
Conversation
The cachix workflow only pushed release artifacts to the cache, leaving them subject to normal GC. Once a path was collected, any consumer pinning a few-weeks-old tag silently fell back to building from source. Pin each release's closure with `cachix pin`, keyed per package+OS so the two matrix runners don't clobber each other's pins. `--keep-revisions 10` bounds storage to fit the cachix free plan while keeping recent releases hittable. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThe PR modifies the Cachix GitHub Actions workflow to add OS-aware pinning for build outputs. The "Build and cache" step now exports the job's matrix OS as an environment variable alongside the existing PACKAGE variable. After pushing the build result to Cachix, a new pin command executes using a package+OS-specific pin name and retains the last 10 revisions, preventing released paths from being garbage-collected during maintenance cycles. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
The
.github/workflows/cachix.ymlrelease job only rancachix pushfor built artifacts, leaving those store paths subject to the cache's normal garbage collection. Once a path was GC'd, any consumer pinning a few-weeks-old release tag silently fell back to building from source instead of pulling the cached closure.This adds a
cachix pinafter the push so released paths are exempt from GC:"$PACKAGE-$OS") so the two matrix runners (ubuntu-latest,macos-latest) don't clobber each other's pins.--keep-revisions 10bounds storage to fit the cachix free plan while keeping the last 10 releases per package per platform hittable.matrix.osis passed throughenv: OSand referenced as quoted"$OS"(the safe pattern for workflow inputs); the tag is already validated against a strict semver regex earlier in the job.Why
Without pinning, the cache is best-effort and decays. Consumers pinning older-but-still-current tags pay an expensive from-source build, defeating the point of publishing to cachix. Pinning makes the retention window explicit and predictable.
Reviewer notes
--keep-revisions 10up/down to trade retention window against cache storage on the free plan.Test plan
cachix pinsuccessfully aftercachix push.kixelatedcache and survives a GC cycle.ubuntu-latestandmacos-latestpins coexist (no clobbering).(Written by Claude)