This repository contains the BoringCache benchmark for Zed.
The release matrix compares one cold seed with target-only, sccache-only, and
combined Cargo plans on fresh runners. Each layer choice and both of Zed's Linux
release commands live in committed .boringcache.toml files under plans/.
The Action activates the selected plan inside the clean Zed checkout so the CLI
measures source freshness against Zed itself, while the workflow remains only a
lane/phase selector.
The GitHub workflow selects those plans and leaves cache identity, target
selection, and compiler-cache selection to the BoringCache CLI.
Both release workflows select Clang and Clang++ explicitly, matching Zed's
Linux bundle recipe even when sccache wraps the C and C++ compilers.
cargo-layer-source.env pins the reviewed adjacent
source pair for that matrix independently of the continuously advancing rolling
source. Every matrix plan tag carries the pinned head identity, so a later
rolling sync cannot silently turn the cold seed into an older-cohort restore.
The root .boringcache.toml owns the persistent rolling
chain. .github/workflows/zed-cargo-product.yml
owns the independent release matrix.
The RunsOn cache comparison builds the primary Linux release command on fresh 16 vCPU, 64 GiB Flex runners in us-east-1. RunsOn Magic Cache and BoringCache both cache Cargo registry, Git, and target data. Each provider builds the pinned base revision cold, rebuilds that revision on a fresh runner, then builds its adjacent revision on a third runner. Every phase writes a new cache snapshot and checks the release binary. Compare total cache and build time; the setup and build columns split work differently for the two providers. Inspect the Magic Cache job logs for fallback warnings before using its result.
The target plus sccache comparison repeats those phases with the same source and Cargo command. BoringCache uses its Cargo target and remote sccache adapters. Magic Cache archives the target and a local sccache directory after each build. The cache snapshots have different storage formats, so compare the completed build and cache path as a whole.
The sccache-only comparison uses the same build and output checks, but neither provider restores target on a fresh runner. Both retain Cargo registry and Git dependencies; BoringCache uses remote sccache, and Magic Cache archives a local sccache directory.
Run the connection workflow once and approve the repository binding to boringcache/benchmark-runs-on-s3-clean before dispatching the comparison.
The scheduled sync selects the newest source with a successful upstream
check_dependencies result and dispatches a separate rolling run. That run
benchmarks and publishes the source, then advances benchmark-source.env on
main only after the build succeeds. Commits with broken dependency state are
skipped as source points, while the build still starts from the last published
cache seed and records the exact commit distance. The rolling build executes
Cargo directly, as required by BoringCache's Cargo adapter. Sync, scheduled
rolling, and manual rolling runs share one concurrency group; queued schedule
ticks may collapse, but the source pin cannot advance past an unbuilt commit.