ci(cache): setup-soldr PR saves blow the 10 GB cache (one PR offered ~23 GB, 14.6 GB of cook bases) — adopt setup-soldr#527 and guard it

[zackees]

Failure

kernal-api's Actions cache is over GitHub's 10 GB repository limit, driven by setup-soldr saving from pull-request runs. One PR (#354) offered about 23 GB of entries on refs/pull/354/merge:

family	ref	entries	size
cook-base	PR	6	14.6 GB (~2.4 GB each)
setup-soldr-buildcache	PR	3	3.8 GB
setup-soldr-prepare	PR	4	2.3 GB
setup-soldr-cargoregistry	PR	6	1.1 GB
solo-toolchain	PR	5	0.9 GB
cook-delta / setup-soldr-buildcache / solo-toolchain / setup-soldr-cargoregistry	main	6	~4.3 GB

PR-ref entries are restorable only by that PR, so they evict main's reusable entries and leave later runs cold.

Mechanism

Every CI job runs zackees/setup-soldr (pinned c2a3b96, v0.9.77) with the default prebuild-deps: soldr-cook and caching on, so each job × target writes a cook base, build cache, prepare, cargo-registry and solo-toolchain entry on PRs as well as on main. setup-soldr has no main-action input to restore without saving: zackees/setup-soldr#527.

Proposal

• Primary: once setup-soldr#527 ships, bump all seven pins (ci.yml x3, release.yml x2, auto-release.yml, macos-x64-tests.yml); with the default save-cache: auto, PR runs stop saving.
• Check whether jobs cooking the same graph can share one cache-key-suffix per target and feature shape. Here one cook base is ~2.4 GB, so each duplicate costs heavily.
• Guard: extend ci/test_native_proof_jobs.py (or a sibling test) to fail if any setup-soldr step can save on pull_request without an explicit exemption. RED once #527's input exists and a step omits it; GREEN when every step uses the policy.

Acceptance criteria

• After a PR run, no new refs/pull/* cook/build/prepare/registry/toolchain entries; main keeps one set per target × shape; the total stays under 10 GB.
• PR CI restores warm from main with no wall-time regression.

Related

• Blocked by fix(cache): never save durable caches from pull-request runs by default — they are unreachable and fill consumers' 10 GB budget (zccache 11.75 GB, kernal-api ~23 GB offered) setup-soldr#527. Part of the cross-repo cache-footprint meta (linked from the parent issue).

[zackees]

Reopened for the remaining live quota overage. Current GitHub cache usage is 10,829,310,998 bytes (28 listed entries, same byte total), above the 10 GiB repository cap. Four main-ref cook-base-v2 entries keyed to Soldr 0.9.22 total 7,800,315,246 bytes; setup-soldr 0.9.23 cook bases restore exact-only, so current producers cannot use those older generations. The reviewed follow-up PR pins all first-party producers to Soldr 0.9.23 and adds a main-only post-producer retention job that deletes only older main cook-base keys, verifies a current generation exists before deleting, tolerates concurrent 404s, and enforces a 9.5 GiB live budget using max(usage endpoint, listed bytes). It preserves current-version shapes, other cache families, and PR refs. Closing only after the merged cleanup run and actual quota audit.

[zackees]

Reopening while validating full exact-main producer cycle 36281990983. The initial post-merge stale-generation sweep brought usage to 3,028,995,752 B, but that ordinary push run skipped cross-target producers; need confirm the full current-version producer matrix does not regrow above the budget before closing.

[zackees]

Post-merge acceptance verified after PR #362 (#362), exact-head ci-full run 36294072027, and main retention run 36296871686 (SUCCESS). The policy selected old lock-hash entries only when a nonempty replacement with the checked-out Cargo.lock hash existed in the same main-ref cache shape; this was not based on maximum cache ID. Current lock hash prefix: 5e524d4298978a25; retired lineage: f594fff1c7c78900 → matching current-hash shape.\n\nBefore cleanup: main had 48 entries / 10,709,826,347 B; the full list additionally contained 6 unchanged refs/pull/360/merge entries / 1,480,012 B (54 total listed / 10,711,306,359 B). The reviewed main-only cleanup deleted exactly IDs 8164529344, 8164557132, 8164564406, 8164621792, 8166167772, 8166170339, 8166831734, 8166839034, 8167094460 (9 entries / 1,428,179,043 B). After: main has 39 entries / 9,281,647,304 B; total list is 45 entries / 9,283,127,316 B, including the same six PR entries. Actions usage and full list converge at 9,283,127,316 B, below the 10,200,547,328 B (9.5 GiB) guard. Main count/byte deltas equal exactly the reviewed 9 deletions; no other baseline entries were evicted. A fresh policy dry-run reports zero candidates. The main Linux producer and retention job both succeeded.