Repository navigation
Build caching for the deploy actions (sccache) #346
Description
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:
- Spec:
docs/superpowers/specs/2026-08-20-edgezero-deploy-build-caching-design.md(v6.14 — sccache pivot) - Container sub-plan:
docs/superpowers/plans/2026-08-20-build-cache-container.md
Approach (v6.14)
Caching is delivered by a reusable workflow (workflow_call) running in a pinned container (single-manifest linux/amd64, digest-pinned, baking the Rust toolchain + wasm32-wasip1 + a pinned sccache + the Fastly CLI), on GitHub-hosted runners only. The cache mechanism is a fresh CARGO_TARGET_DIR + an action-owned pinned sccache disk cache (Cargo's own recommendation): content-addressed, so it works for any source (including EdgeZero's own unpublished git dependency), needs no custom target/ pruner, and caches no dependency source (compiled objects only). cache is off by default; provenance + container execution are unconditional.
Sub-plans (dependency-ordered)
- Pinned build container — Dockerfile, GHCR publish (verify-by-digest → reviewable
image.jsonPR), digest-pin gate. Everything keysplatform-idon this digest. - Cached build path — reusable workflow +
prepare/compilesplit + ownedactions/cacherestore/save overSCCACHE_DIR+ config/source closure. - Provenance — committed JSON Schema + canonical-JSON validation,
validate-app-cli-provenance,compute-app-cli-identity, the singleExpectedIdentitycontract. - Consumer integration —
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.json digest-pin validator) is in the linked PR.
Out of scope (v1)
Caching .crate archives; workflow-bound artifact attestation; git/alternate-registry dependency authentication; a trusted self-hosted runner mode; non-default feature sets; non-Fastly adapters.
Activity
gauravtiwari commentedon Sep 25, 2026
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.
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
aram356 commentedon Sep 28, 2026
Won't fix since simple caching addressed by PR #381