Repository navigation
perf(ci): pin Rust deps with a GC root so the sticky disk keeps them - #1274
Conversation
The linux native build rebuilt the entire crate dependency set (~190s) on every run, even though the `ccusage-deps` derivation hash is identical across runs. The crane cargoArtifacts path has no GC root once the final binary is built, so the Blacksmith sticky disk drops it on commit and the next run recompiles all deps from scratch. Expose the static build's `cargoArtifacts` via passthru and, after the build, pin it with a GC root under the mounted Nix store (`/nix/ccusage-ci-gcroots/deps`). The root persists with the sticky disk, so the deps stay warm and subsequent runs should reuse them instead of rebuilding.
|
This run was cancelled 🛑 The workflow was cancelled before completion. Please check the link below for details. |
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThis PR adds Nix GC root pinning for Cargo dependency artifacts in CI. The ChangesCargo dependency cache persistence
Possibly related PRs
Suggested reviewers
Poem
🎯 2 (Simple) | ⏱️ ~8 minutes ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
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
The linux native build rebuilds the entire crate dependency set (~190s) on
every run — including on
main— even though theccusage-depsderivationhash is identical across runs (verified from the build logs). So the deps are
deterministic but never served from cache.
Root cause
crane's
cargoArtifacts(deps-only) store path has no GC root once the finalbinary is built. The Blacksmith sticky disk appears to drop unreferenced paths
on commit, so the deps are gone by the next run and get fully recompiled.
Fix (hypothesis to validate in CI)
cargoArtifactsviapassthru.nix build .#ccusage-static, pin the deps with a GC root on the mountedNix store (
/nix/ccusage-ci-gcroots/deps). The root lives on the sticky disk,so the deps survive the commit and the next run reuses them.
How to verify
After this merges, the second
build-linux-*run onmainshould drop from~190s to ~40s (deps reused, only the final binary recompiles). If it does not,
the sticky disk is dropping paths for a different reason (e.g. not committing the
full store) and we'll need to look at the Blacksmith disk config instead.
Same root cause affects the test job's
cargoTest(#1273) and macOS; if thisworks, I'll roll the GC-root pin out to those too.
Summary by cubic
Pins Rust dependency artifacts with a Nix GC root so the Linux native build reuses
cranecargoArtifactsacross runs instead of rebuilding. Exposesccusage-static’scargoArtifactsviapassthruand in CI links them to/nix/ccusage-ci-gcroots/depswithnix build '.#ccusage-static.cargoArtifacts', targeting ~190s → ~40s on the second run.Written for commit c766768. Summary will update on new commits.
Need help on this PR? Tag
/codesmithwith what you need. Autofix is disabled.Summary by CodeRabbit
Chores