Skip to content

ci: pin released cachix paths so consumers don't fall back to building#1555

Merged
kixelated merged 1 commit into
mainfrom
claude/recursing-tesla-1265da
May 30, 2026
Merged

ci: pin released cachix paths so consumers don't fall back to building#1555
kixelated merged 1 commit into
mainfrom
claude/recursing-tesla-1265da

Conversation

@kixelated
Copy link
Copy Markdown
Collaborator

Summary

The .github/workflows/cachix.yml release job only ran cachix push for 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 pin after the push so released paths are exempt from GC:

  • Keyed per package + OS ("$PACKAGE-$OS") so the two matrix runners (ubuntu-latest, macos-latest) don't clobber each other's pins.
  • --keep-revisions 10 bounds storage to fit the cachix free plan while keeping the last 10 releases per package per platform hittable.

matrix.os is passed through env: OS and 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

  • Tune --keep-revisions 10 up/down to trade retention window against cache storage on the free plan.
  • Alternatives considered: permanent per-tag pins (strongest guarantee, unbounded growth), a larger cachix plan, or a self-hosted cache. Bounded per-package revisions is the cheapest fix that addresses the silent-fallback problem.

Test plan

  • Cut a release tag and confirm the workflow runs cachix pin successfully after cachix push.
  • Verify the pin appears in the kixelated cache and survives a GC cycle.
  • Confirm both ubuntu-latest and macos-latest pins coexist (no clobbering).

(Written by Claude)

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>
@kixelated kixelated enabled auto-merge (squash) May 30, 2026 16:16
@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented May 30, 2026

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 4a33f9bf-b088-449d-b615-4709bd96b68d

📥 Commits

Reviewing files that changed from the base of the PR and between 9e9cd02 and f41557b.

📒 Files selected for processing (1)
  • .github/workflows/cachix.yml

Walkthrough

The 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)
Check name Status Explanation
Title check ✅ Passed The title clearly and concisely summarizes the main change: adding cachix pinning to prevent consumers from rebuilding released paths that might be garbage collected.
Description check ✅ Passed The description is directly related to the changeset, providing thorough context about why pinning is needed, how it's implemented, and what trade-offs were considered.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
✨ Simplify code
  • Create PR with simplified code
  • Commit simplified code in branch claude/recursing-tesla-1265da

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@kixelated kixelated merged commit 4833e5c into main May 30, 2026
1 check passed
@kixelated kixelated deleted the claude/recursing-tesla-1265da branch May 30, 2026 16:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant