Repository navigation
chore(ci): remove the dead weekly sticky-disk GC workflow - #1295
Conversation
The scheduled Sticky Disk GC never collected anything useful. Blacksmith sticky disks are keyed per `github.job` (`<repo>-nix-<os>-<arch>-<github.job>`), so the GC job mounted its own `...-nix-store-gc` disk and ran `nix-collect-garbage` there — never touching the disks that npm-publish, perf, release, or update-pricing actually grow. It is also redundant now: the heavy build jobs (check, test, build-native) moved to cache-nix-action via setup-linux-nix-action-cache, which self-trims with `gc-max-store-size-linux`, and macOS does the same with `gc-max-store-size-macos`. The remaining sticky-disk users only pull lightweight toolchain closures, each on its own per-job disk, and Blacksmith storage is effectively unlimited.
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
ccusage-guide | 7d91632 | Commit Preview URL Branch Preview URL |
Jun 12 2026, 12:12 AM |
📝 WalkthroughWalkthroughThe GitHub Actions workflow file Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
![pullfrog[bot]](https://avatars.githubusercontent.com/in/1768019?s=60&v=4){kind=small}
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes — Removes the dead .github/workflows/cache-gc.yaml weekly sticky-disk GC workflow, which was redundant (heavy jobs self-trim via cache-nix-action) and never actually cleaned the right disks (each sticky disk is per-job, so the GC workflow only GC'd its own unused disk).
- Remove dead
cache-gc.yamlworkflow — Deletes the scheduled weekly Nix store GC that was keyed to its own per-job sticky disk and never touched the disks that actually grow.
Big Pickle (free via Pullfrog for OSS) ｜ 𝕏
ccusage
@ccusage/ccusage-darwin-arm64
@ccusage/ccusage-darwin-x64
@ccusage/ccusage-linux-arm64
@ccusage/ccusage-linux-x64
@ccusage/ccusage-win32-x64
commit: |
ccusage performance comparisonPR SHA: This compares the PR package against the configured base package on the same CI runner. Package runner startupExecution setup measures any pre-benchmark package materialization used by the execution benchmark. Bunx temp cache measures one
Cached bunx execution performanceRuns the same large fixture through Fixtures: Claude
Package runtime diagnosticsCompares the PR package wrapper, the installed native optional dependency binary, and the workspace release binary on the same large fixture. This identifies whether slow package results come from JavaScript wrapper overhead, the published native binary build, or the Rust core itself. Fixtures: Claude
Committed fixture performanceCommitted small fixtures for stable PR-to-PR feedback and explicit Claude/Codex command coverage. Fixtures: Claude
Large real-world-shaped fixture performanceGenerated fixtures shaped from aggregate local log statistics: thousands of JSONL files, many small sessions, and a long tail of larger sessions. No real prompts, paths, or outputs are stored in the fixtures. Fixtures: Claude
Artifact size
Lower medians and smaller artifacts are better. CI runner noise still applies; use same-run ratios as directional PR feedback, not release guarantees. |
ccusage performance comparisonPR SHA: This compares the Rust PR release binary against the configured base package on the same CI runner. Package runner startupExecution setup measures any pre-benchmark package materialization used by the execution benchmark. Bunx temp cache measures one
Cached bunx execution performanceRuns the same large fixture through Fixtures: Claude
Package runtime diagnosticsCompares the PR package wrapper, the installed native optional dependency binary, and the workspace release binary on the same large fixture. This identifies whether slow package results come from JavaScript wrapper overhead, the published native binary build, or the Rust core itself. Fixtures: Claude
Committed fixture performanceCommitted small fixtures for stable PR-to-PR feedback and explicit Claude/Codex command coverage. Fixtures: Claude
Large real-world-shaped fixture performanceGenerated fixtures shaped from aggregate local log statistics: thousands of JSONL files, many small sessions, and a long tail of larger sessions. No real prompts, paths, or outputs are stored in the fixtures. Fixtures: Claude
Artifact size
Lower medians and smaller artifacts are better. CI runner noise still applies; use same-run ratios as directional PR feedback, not release guarantees. |
* ci(release): shallow-clone the tag in native build jobs The native build jobs checked out the release tag with fetch-depth: 0, but nothing in the build path reads git history: CI builds the same outputs from a default shallow checkout. The full clone cost up to 41s on build-windows-x64 in run 38470996208, which finished within 20s of the slowest leg. * ci: keep the Linux Nix store on a Blacksmith sticky disk The cache-nix-action store cache misses most of the time. Across ~25 CI pushes to main between 2026-09-25 and 2026-10-13, the native build legs restored an entry in only 3-6 of ~19 runs each (macOS and Linux alike), and a hit roughly halves the build step (linux-arm64: 82s vs 213s). Blacksmith's Actions cache allows 25 GB per repository per week with LRU eviction, while the per-commit keys introduced in #1296 write a fresh 1.3-3 GB entry for every job on every run: ~12 GB per push to main, ~6 GB per PR run, up to 2.5 GB per hourly update-pricing run. #1296 assumed the backend was effectively unlimited; it is not. Even on a hit, restoring takes ~60s and the post-job save another ~40s. On Blacksmith Linux runners, mount /nix from a sticky disk instead. A job gets a copy-on-write clone of the last committed snapshot, so the whole store is present at mount time with no restore or save step and nothing counted against the cache quota. macOS and GitHub-hosted runners have no sticky disks and keep using cache-nix-action. #1296 dropped an earlier sticky-disk setup. This one avoids its problems: - Keys are per job and matrix leg but carry no workflow name, so release.yaml's build-native-packages mounts the disk ci.yaml keeps warm on every push to main instead of starting cold. autofix, which only runs on pull requests and so would never commit, borrows preflight's disk via the new disk-job input; both build the treefmt closure. - The old trim dropped Crane's cargoArtifacts because nothing rooted them (#1274, #1279). The Linux build now roots them inside /nix/var/nix/gcroots, which persists with the disk, and keep-derivations/keep-outputs make GC keep their build-time closure (toolchain, vendored sources) too. - The weekly GC workflow (#1295) mounted its own disk and never touched the real ones. Trimming now happens in the job that commits: once the disk is over half full, `nix-collect-garbage --delete-old` runs before the job adds to the store. Jobs without persistent roots go cold once per trim. Only runs on main that are not pull_request(_target) events commit, whatever `save` says, so pull request code (including forks) can read main's store but never write the store that main and releases build from. cache-nix-action keeps its existing behaviour, now also gated by `save`. Not confirmed from Blacksmith's documentation: the disk's capacity (hence the relative threshold and the `df` log on every run) and which snapshot wins when two runs commit the same key concurrently. Either outcome is a valid store for a cache. * ci(release): stop persisting the Nix store from release builds Release builds now mount the Linux sticky disk that CI commits on every push to main. Committing it from the release as well would only race those commits with an equivalent store. On macOS, the release's own cache-nix-action entries never survive to the next release under Blacksmith's cache eviction, yet each save took ~40s (build-mac-arm64 and build-mac-x64 in run 38470996208) before the job could finish and let the npm job start. Add a save-nix-cache input to both native build actions, forwarded to setup-nix-cache, skip rooting the Crane artifacts when nothing will be saved, and pass save-nix-cache: false from release.yaml. * ci: mount test's Nix sticky disk in the perf comment legs ccusage-perf-comment only runs on pull requests, and pull requests never commit a sticky disk, so its own per-leg keys would stay freshly formatted on every run. Mount the disk test commits on every push to main instead: it installs `just` and resolves the same flake inputs. Both legs mount it read-only, so the per-runtime cache-scope that kept their saves apart is no longer needed. Reported by pullfrog in review.
Summary
cache-gc.yaml(the scheduled "Sticky Disk GC") never actually collected the stores it was meant to.Blacksmith sticky disks are keyed per
github.job(<repo>-nix-<os>-<arch>-<github.job>, seesetup-linux-blacksmith-sticky-disk). The GC workflow runs as jobnix-store-gc, so it mounts a...-nix-store-gcsticky disk — its own, used by nothing else — and runsnix-collect-garbagethere. The disks thatnpm-publish,ccusage-perf-comment,release, andupdate-pricinggrow are never touched.It is also redundant now:
check,test,build-native) moved tocache-nix-actionviasetup-linux-nix-action-cache, which self-trims withgc-max-store-size-linux: 2GB.gc-max-store-size-macos.So the workflow is pure dead weight. Removing it.
Need help on this PR? Tag
/codesmithwith what you need. Autofix is enabled.Summary by cubic
Removed the weekly Sticky Disk GC workflow (
.github/workflows/cache-gc.yaml). It only mounted its own per-job sticky disk and never cleaned the disks that actually grow; heavy jobs now self-trim viasetup-linux-nix-action-cachewithgc-max-store-size-linux/gc-max-store-size-macos.Written for commit 7d91632. Summary will update on new commits.
Summary by CodeRabbit