Open and answer this issue on GitHub.
decision · opened 2026-10-24 · updated 2026-10-24 · 2 comments
The owner asked (2026-10-24) whether CI can use a cache so that, as the compiler becomes modular (#667 step 4, #793), a run rebuilds only what changed; a run takes about 30 minutes. Decision basis: docs/ci-cache.md; related: docs/long-jobs.md (#794), docs/modular-compiler.md (#793).
Job and step timestamps of runs 40091734854 (bbf2cff8, green), 40090955357 (c886924e, green), 40089908988 (6e99a88d, red):
| run 1 | run 2 | run 3 | |
|---|---|---|---|
| created -> jobs start (queued behind the previous run) | 618 s | 181 s | - |
bootstrap_compiler |
792 s | 1104 s | 686 s |
| of it: Test / sweep / build / cache / clippy | 539 / 92 / 79 / 45 / 25 | 790 / 130 / 110 / 26 / 31 | 535 / - / 76 / 41 / 23 |
arm64 |
884 s | 892 s | 874 s |
| of it: Test / build / cache | 711 / 96 / 51 | 695 / 121 / 50 | 723 / 95 / 50 |
| created -> promote done | 1546 s | 1327 s | - |
Post Cache takes 2-3 s: every run is an exact hit on the key Cargo.lock + rust-toolchain.toml (lock last changed 825f03e8, 2026-10-21), so the cache is never saved again; checkout mtimes make Cargo rebuild every workspace crate anyway. Only third-party crates are reused.Test into compiling/linking the 267 test binaries and running them is unknown (125 of 267 test files hand emitted programs to rustc).lower-std per-file cache is keyed on the running binary’s hash (a test binary in CI): it would always miss if restored. Not cached.Sound caches only (content-hashed or Cargo-fingerprinted; never restored mtimes; keys on lock file, toolchain, OS, arch, profile; only develop pushes save; one clean build per commit stays). Details and rejected options (sccache, git restore-mtime, nightly checksum freshness) in the doc.
Owner: (a) may develop runs run side by side instead of queueing (step 6)? promote already only fast-forwards to a tested commit and skips one main already has. Cost: runner minutes. (b) Third-party actions Swatinem/rust-cache and taiki-e/install-action (nextest) acceptable? (c) Step 5: incremental x86 build with arm64 as the clean build, after #667 step 4.
bootstrap_compiler and arm64, a step Build the tests = cargo test --workspace --release --no-run, then Test as now. Test: the next run’s job API shows both steps; record the shares in docs/ci-cache.md.cargo-nextest, run cargo nextest run --workspace --release --no-fail-fast plus cargo test --workspace --release --doc; keep NIKAIA_DUMP_ACCEPTED and the sweep step. Test: same test count passed as cargo test (compare the summary), a deliberately failing test fails the job.actions/cache steps with Swatinem/rust-cache@v2 (save-if: github.ref == 'refs/heads/develop', its key includes rustc version, lock file, job, arch). Test: second run restores, workspace crates still compiled (Compiling nikaia in the log).cargo nextest archive, k runners with --partition count:i/k, promote needs all. Test: each shard’s count sums to the whole.bootstrap_compiler builds and tests with --profile fast; actions/cache on target/fast keyed ...-fast-<run_id> with restore-key prefix, saved on develop only; arm64 stays plain release; weekly schedule run without the build cache. Measure: units re-optimised per commit (modular-compiler.md), cache size against the 10 GB limit.concurrency group only for pull requests. Test: two pushes a minute apart both run; the older finishing last leaves main alone.Parked by the owner, 2026-10-24. The plan is not enough. The build has to become more cacheable first (modular units: #667 step 4, #793). Until then there is no order on this issue. Recorded in one line in docs/ci-cache.md (commit 42ecccdc). The label stays decision.
Generated by Claude Code
Re-check, 2026-10-24 evening (architect; step times from the job API, nothing re-measured).
Last green run, 40109418638 (64661b76). The two jobs run in parallel, so a run takes about 10 minutes, plus 0.7 min for promote.
bootstrap_compiler, 9.4 min: cache restore 0.9, build 1.4, clippy 0.4, build the tests 1.1, Test 3.7, accepted sweep 1.8.arm64, 9.9 min: cache restore 1.9, build 1.9, build the tests 1.1, Test 4.6.This is down from about 25 minutes when this issue was written. Step 1 of this issue (building the tests apart from running them) is built, and the merge of the 267 test binaries into one (539ea132) cut arm64’s Test from about 711 s to about 276 s.
The cache, unchanged since the issue was written.
actions/cache is keyed on Cargo.lock plus rust-toolchain.toml; the lock last changed in 825f03e8 on 2026-10-21. So every run is an exact hit and the cache is never saved again.What is slow now is not the cache.
develop failed: 9 at Check formatting or badges, in the first 30 s, plus arm64 Test (exit 101, log behind a 403).cancel-in-progress applies only to pull requests..md files and still pay a full run.Options per commit, with what they save:
nikaia, nikaia-std) change on every compiler commit, so it misses on them. Gain: little.--profile fast with target/fast saved per run (step 5): saves perhaps half of the 2.5 min, but uploading a 3 GB target costs 1-2 min. Gain: about zero now.lower-std results: since #801 the key is the compiler’s source fingerprint, which changes on every compiler commit. It hits only where the run could have been skipped anyway.docs/specification/ and the badges check stay in.What still holds of the owner’s park: the build becomes more cacheable through #667 step 4 and #793. Steps 2-6 here stay parked. A docs-only skip and making develop green again are outside that park and need no cache.
Generated by Claude Code