CI Caching Is Not One Cache — GitHub Actions, Incredibuild, and Islo
MVP POC · GitHub Actions acceleration
Fresh CI runners should not rebuild the world.
This is a small MVP POC for choosing the right GitHub Actions cache.<br>Native caches are unbeatable when the same workspace is already warm.<br>Incredibuild CI/CD acceleration<br>is strongest when runners are fresh, ephemeral, or invalidated by dirty<br>timestamps, because its proprietary Build Cache reuses compiler artifacts<br>across jobs. Islo<br>supplies disposable runner infrastructure.
C++ flagship<br>RocksDB<br>263s → 14s<br>18.8x with restored IB cache
Rust CI story<br>Tokio<br>46s → 13s<br>fresh GitHub runner made warm
native vs IB<br>touch test<br>38s → 13s<br>dirty mtimes, same content
what to use when
The honest comparison.
The useful question is not "which cache is best?" It is "what got<br>invalidated?" Incredibuild is compelling when compiler work is the<br>expensive part and the runner starts clean.
SituationUse firstWhy
Fresh C/C++ or Rust runnerIncredibuild Build CacheRestores compiler artifacts into a clean job.
Same workspace, no source changesNative build cacheNothing beats a hot local `target/`, `GOCACHE`, or incremental state.
Warm workspace, files touchedIncredibuild Build CacheDirty mtimes force native rebuilds; content-identical compiler work can still be reused.
Go builds`GOCACHE` + `GOMODCACHE`Go already has the right content-aware cache.
Docker image buildsBuildKit cacheLayer reuse is the real accelerator.
JS / TypeScriptnpm/pnpm + `.tsbuildinfo` + bundler cacheTool-native caches beat generic compiler-cache claims here.
the rule
Native warm state wins locally. IB helps when warm state disappears.
Native cache
Best when the same machine keeps its build directory and nothing changes.
Tokio Cargo warm: ~0s
Incredibuild Build Cache
Best when a fresh runner can restore content-addressed compiler work.
Tokio IB restored: 13s
Touch invalidation
When mtimes are dirty but contents are identical, native rebuilds; IB reuses.
Cargo touch: 38s · IB touch: 13s
measured evidence
POC numbers that shaped the story.
ecosystemproject / scenariobaselineacceleratedread
C++facebook/rocksdb263s14sIB flagship
C++duckdb/duckdb293s16sIB flagship
C++llama.cpp131s13sIB strong
Rusttokio compile46s13sIB strong
Rusttokio full test75s43sIB helps compile slice
Rusttokio after touchCargo 38sIB 13sbest native-vs-IB proof
JavaMaven forked javac XL15s9sselective candidate
Gonektos/act34s0s nativeuse GOCACHE
JS/TSTypeScript compiler6s4s nativeuse tool cache
DockerBuildKit control11s3suse BuildKit cache
decision
What should this workflow cache?
Pick the workload shape. The answer should change by ecosystem.
Language
C / C++<br>Rust<br>Java<br>Go<br>JavaScript / TypeScript<br>Docker
Runner state
fresh / ephemeral<br>same workspace is warm<br>warm but sources were touched
recommended layer
IB Build Cache
Heavy compiler work on a fresh C/C++ runner is the strongest measured<br>fit for Incredibuild Build Cache.
runner context
Faster runners still need the right cache.
GitHub job
Islo runner
IB cache restore
compiler build
cache save
Whether you use GitHub Actions,<br>faster hosted runners such as Blacksmith,<br>or disposable runners on Islo,<br>the question is the same: what state is worth restoring into a clean<br>machine? Dependencies, native build state, BuildKit layers, and<br>Incredibuild CI/CD acceleration<br>compiler artifacts answer different parts of the job.
POC demo set
Show three stories, not one claim.
C++ flagship: DuckDB or RocksDB for the 18x restored-cache win.
Rust CI: Tokio for fresh runner, full test, and touched-source variants.
Native-cache contrast: Go or Docker to show when IB is not the right layer.