Repository navigation
Build caching for the deploy actions (sccache) #346
Description
Activity
Hey @aram356,
I'm Gaurav, the founder of BoringCache. I found this issue while looking at builds that repeatedly compile work another machine has already finished. BoringCache gives shared storage across builds and runners or local development. You can use managed storage or your own S3-compatible bucket while keeping your compiler, container and provenance checks.
I tested the app CLI build in a public fork, starting with a cold seed and then building four successive application revisions on fresh GitHub-hosted runners. That sequence included a documentation change and a dependency upgrade. All 10 jobs passed. BoringCache reused compiler results through the changes and recorded zero cache read or write errors.
Whole-job time GitHub-backed sccache BoringCache Cold seed 7m01s 5m57s Next four commits, combined 10m40s 10m28s The four follow-on jobs were effectively tied end to end. GitHub's seed also had 41 cache write errors, followed by 41 misses on the first commit; on commits 2–4, both backends recorded the same hit and miss counts. The comparison used sccache's native GitHub cache backend, so I'd still want to compare against the directory-cache path in your design.
What I've established so far is that BoringCache can keep this compiler work reusable across changing builds while providing shared storage outside a repository's GitHub cache. I see #347 is putting the container and trust checks in place first. If you're open to it, I'd be happy to put together a small PR for the cached build path, preserve those checks and your credential boundaries, and let you judge it on your own deploy runs.
Cheers,
Gaurav
Summary
Implement build caching for the EdgeZero deploy actions so a deploy no longer pays a ~10-minute cold Rust compile every run (observed on
stackpop/trusted-server-deployer, which checks out a separate application repo and builds its CLI).The design is merged (via #316) and lives at:
docs/superpowers/specs/2026-08-20-edgezero-deploy-build-caching-design.md(v6.14 — sccache pivot)docs/superpowers/plans/2026-08-20-build-cache-container.mdApproach (v6.14)
Caching is delivered by a reusable workflow (
workflow_call) running in a pinned container (single-manifestlinux/amd64, digest-pinned, baking the Rust toolchain +wasm32-wasip1+ a pinnedsccache+ the Fastly CLI), on GitHub-hosted runners only. The cache mechanism is a freshCARGO_TARGET_DIR+ an action-owned pinnedsccachedisk cache (Cargo's own recommendation): content-addressed, so it works for any source (including EdgeZero's own unpublished git dependency), needs no customtarget/pruner, and caches no dependency source (compiled objects only).cacheis off by default; provenance + container execution are unconditional.Sub-plans (dependency-ordered)
image.jsonPR), digest-pin gate. Everything keysplatform-idon this digest.prepare/compilesplit + ownedactions/cacherestore/save overSCCACHE_DIR+ config/source closure.validate-app-cli-provenance,compute-app-cli-identity, the singleExpectedIdentitycontract.active-version-fastly, per-consumerExpectedIdentity, the one action-owned Docker launcher, production-only recovery.Rollout is atomic at one EdgeZero SHA (provenance + container execution change every build; the direct-composite producer is retired, so adopters move to a two-job topology; runner floor rises to Actions Runner 2.336.0 for the self-repo
$/reference).Status / scope of the tracking PR
The design has been through extensive review and is still being hardened. This issue tracks the implementation, landing in dependency order behind the container. The first increment (the fail-closed
image.jsondigest-pin validator) is in the linked PR.Out of scope (v1)
Caching
.cratearchives; workflow-bound artifact attestation; git/alternate-registry dependency authentication; a trusted self-hosted runner mode; non-default feature sets; non-Fastly adapters.