ci: seed the test compilation cache from one clean build

[teamleaderleo]

What

refresh-test-compilation-cache restored its own last seed by prefix before rebuilding, so every scheduled run stacked another build's objects onto one CAS. Xcode keeps the primary generation and the upstream it faults objects in from, and that pair grew until it crossed the 5 GiB save bound today:

scheduled run	pruned CAS size
09-20 07:33	3,542,996 KiB	cold, no prefix restore
09-21 06:54	3,907,208 KiB
09-21 12:37	4,998,584 KiB
09-21 18:33	5,008,564 KiB
09-22 01:00	5,020,552 KiB
09-22 06:43	5,019,980 KiB
09-22 12:38	5,027,256 KiB	last run that saved
09-22 18:33	5,293,516 KiB	over the 5,242,880 KiB bound, save skipped

Past the bound the save step is skipped, so the next run restores the same older entry and lands past the bound again. nightly.yml already documents that state for the Release seed:

Nothing is saved, so the next build restores the same older entry and lands here again: the cache freezes at its last saved entry until the bound (and COMPILATION_CACHE_LIMIT_SIZE) is raised.

The pruner is not at fault. It correctly kept v1.9, v1.10 and removed nothing: with two live generations there is nothing stale to drop.

Change

Keep the exact key, drop the prefix fallback. The exact key still short-circuits a re-run of the same revision, which is the only case it ever hit — a prefix match sets cache-hit to false, so it never skipped a step, it only pre-populated the CAS.

Seeding from one clean build is better on every axis I could measure:

• Bounded. 3.5 GiB, so the bound stops being reachable instead of being raised.
• Complete. The build it seeds from is main, so a cold CAS already covers all of main. The stacked objects only covered older revisions of main, which is what a pull request is least likely to match.
• Faster to produce. The one cold run took 18 min; the warm ones took 19, 19, 21 and 25.
• Faster to consume. Every pull request restores this entry, so it is ~1.5 GiB less to download on each one.

Verification

• tests/test_ci_test_compilation_cache_seed.sh fails on the first commit, passes on the second.
• The new guard checks both directions, because they differ: the seeder must not fall back to a prefix, and admission must, since its exact key names a base revision no seeder run ever built.
• Full guard sweep: 119 commands. Three fail, all three identically on clean origin/main — test_check_ghostty_zig_workflows.py (no bashlex locally), test_ghostty_zig_version_sync.sh (ghostty submodule not checked out), and test_review_fabric.py, which is red on origin/main at 5a848ea and unrelated to this change.

Relationship to #13754

Independent, and both are needed. #13754 makes the seed reachable by a pull request at all; this makes it keep updating. #13754 also resets the size ratchet as a side effect, because a new runner means a new fingerprint and so the first run finds no prefix to stack on — but without this change the ratchet would just climb back to the bound and freeze again, which the table above shows takes about three runs.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

---

Summary by cubic

Stops the test compilation cache seed from growing past the 5 GiB save bound and freezing at its last saved entry. The seeder restored its own last seed by prefix, so each scheduled run stacked another build's objects onto the CAS until it crossed the bound, at which point saving was skipped and the cache could no longer update.

Seeding from one clean build keeps the cache bounded and current: 3.5 GiB instead of 5.0 GiB, covers all of main, and takes 18 min to produce instead of 19–25.

• Keeps the exact-key restore, which still short-circuits re-runs of the same revision, and drops the prefix fallback.
• Adds a guard for both directions: the seeder must not prefix-restore, while the admission path must keep its prefix fallback since its exact key names a base revision no seeder run built.

^{Written for commit c8de165. Summary will update on new commits.}

[coderabbitai]

Warning

Review limit reached

Next included review available in 20 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used all 10 included reviews currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Repository: manaflow-ai/cmux/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 404ce5fc-e282-49c3-9d82-3246cce928e2

📥 Commits

Reviewing files that changed from the base of the PR and between d7f6648 and c8de165.

📒 Files selected for processing (2)

• .github/workflows/nightly.yml
• tests/test_ci_test_compilation_cache_seed.sh

---

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

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[teamleaderleo]

#13754 and #13797 are complementary, not duplicates — please don't close either as a dupe of the other.

They touch exactly the same two files (.github/workflows/nightly.yml, tests/test_ci_test_compilation_cache_seed.sh), which is why an overlap scan flags them as a collision. They fix different bugs:

• ci: seed the compilation cache on the runner pull requests restore it from #13754 — the seeder ran on vars.MACOS_RUNNER_15 while pull-request admission runs on MACOS_RUNNER_PR. The fingerprint hashes the workspace path and the pools lay it out differently, so the seed existed but was unreachable and every PR compiled cold. Fix: the seeder tracks the pool admission actually restores from.
• ci: seed the test compilation cache from one clean build #13797 — the seeder restored its own last seed by prefix, so every run stacked another build's objects onto the CAS (3.5 → 5.0 GiB over eight runs), crossed the save bound, and then nothing could save again. Fix: exact key only on the seeder, while deliberately keeping the prefix fallback on admission, since admission's exact key names a base revision no seeder run built.

One makes the seed reachable; the other stops it freezing. Landing only one leaves the other bug.

Verified they compose — merging c8de165 (#13797) into a0bb348 (#13754):

merge: clean, no conflicting files
tests/test_ci_test_compilation_cache_seed.sh: exit 0, 14 PASS
  PASS: the seeder runs on the runner pull request admission restores from   (#13754)
  PASS: the seeder seeds from one clean build                                (#13797)
  PASS: pull requests find the seed by prefix                                (#13797)

Both assertions survive together, so merge order does not matter.

Context: per #13742, MACOS_RUNNER_PR is not currently set as a repository variable, so #13754's vars.MACOS_RUNNER_PR || 'blacksmith-6vcpu-macos-15' resolves to the fallback today — correct either way, but worth knowing the variable is doing nothing until an admin sets it.