Platform / Incremental
Product 01Reuse steps and jobs whose inputs have not changed.
Steps and jobs whose inputs have not changed are not run again. You get the same result without paying for the same work twice.
Why it exists
Build caches depend on keys you maintain. A key can miss an include, glob, missing-file check or environment change, which leads to stale results or cold runs. Installs, generators and test setup often change less than the commits that trigger them.
The mechanism, in the order a job meets it.
Each step is traced while it runs. preloop records the file contents it reads, the directories it lists, the symlinks it follows, the files it checks for and finds missing, and the environment variables it reads.
The step identity covers workflow, job, step, matrix values, runner platform and toolchain version. Content digests are SHA-256 per file, and a per-job map avoids re-hashing an unchanged file twice.
On a later commit, preloop re-evaluates each predicate. If all still hold, it reuses the step; a failed predicate or barrier runs it again.
When the inputs match, preloop checks the recording and restores the step’s exit code, outputs and filesystem changes in milliseconds. The next step sees the tree the step would have produced. Files outside those changes are untouched.
If replayed post-state differs from the recording, the entry is quarantined instead of promoted. A timestamp in a build stamp is enough to trigger quarantine.
A job can be reused too. When a compare shows the new commit did not touch anything the job read, preloop carries over its conclusion and outputs, and the job does not run.
Each capability is part of the product today.
Declare no manual key. The step is identified by what it reads, so changes deep in an include chain are detected without a key convention.
The default is to run. Network access, spawned services, unsuccessful exits, unsupported operations and incomplete observations are barriers that cannot be overridden.
Validation compares inputs and fetches outputs instead of rebuilding. The next step receives the restored tree without another build.
A compare carries whole jobs forward when the new commit touched nothing the job observed. Reruns, debug submissions, pull request events and forks never reuse.
preloop refuses Cargo, Gradle and sccache steps. Their own incrementality already makes them cheap, and another layer would add risk without saving work.
Each step exposes its identity, inputs, unchanged count, decision and reason.
Sample / bash
$ preloop-incremental explain --run 0x2f19 --job test --step 3
step 3 poetry install --no-root
identity test / 3 / py3.12 / linux-arm64
inputs read 441 files, 12 listings, 3 symlinks
unchanged 441 / 441
decision reuse
reason inputs match the last green run
restored 70 msIllustrative output: recording writes the evidence; reuse reads it.
No. Build caches trust a key you write. Incremental rechecks the inputs the step actually read, including inputs absent from the key.
The entry is quarantined. A replay with a different post-state is never promoted, and it stays out until a fresh observation replaces it.
The reason code explains it. Common barriers are network access, a spawned service, a failed step and an operation incremental mode cannot model.
Less. Steps that talk to a service are barriers by design, and database-touching steps always run.
A reused job does not execute, so it has no new logs. Its conclusion and outputs carry forward, and the run links to the source record.
Start
We will set it up with you and show you what changes.