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. Native caches are unbeatable when the same workspace is already warm. Incredibuild CI/CD acceleration is strongest when runners are fresh, ephemeral, or invalidated by dirty timestamps, because its proprietary Build Cache reuses compiler artifacts across jobs. Islo supplies disposable runner infrastructure.

C++ flagship RocksDB 263s → 14s 18.8x with restored IB cache
Rust CI story Tokio 46s → 13s fresh GitHub runner made warm
native vs IB touch test 38s → 13s dirty mtimes, same content

what to use when

The honest comparison.

The useful question is not "which cache is best?" It is "what got invalidated?" Incredibuild is compelling when compiler work is the 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.

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, faster hosted runners such as Blacksmith, or disposable runners on Islo, the question is the same: what state is worth restoring into a clean machine? Dependencies, native build state, BuildKit layers, and Incredibuild CI/CD acceleration compiler artifacts answer different parts of the job.

POC demo set

Show three stories, not one claim.

  1. C++ flagship: DuckDB or RocksDB for the 18x restored-cache win.
  2. Rust CI: Tokio for fresh runner, full test, and touched-source variants.
  3. Native-cache contrast: Go or Docker to show when IB is not the right layer.