fix: Make the sccache compile cache actually cache

[anthonyshew]

Why

End-to-end dogfooding against the real Remote Cache (which CI cannot do on PRs — placeholder credentials) surfaced two bugs that made the compile cache pure overhead: a cold 430-crate build produced 812 cache write errors and a 0% hit rate, so the follow-up build paid per-object network misses on top of full compilation.

1. The proxy didn't speak opendal's write dialect. sccache's storage client stats ancestor "directories" with PROPFIND and creates them with MKCOL before any PUT. The proxy only routed GET/HEAD/PUT, so storage initialization failed and every write died without reaching a handler — silently, since unrouted methods produce no proxy logs. The existing tests missed it because they drove the proxy with hand-rolled HTTP instead of the real client.
2. sccache's background server used the global default port (4226). Any user- or CI-image-managed sccache server already on that port captures turbo's wrapper traffic with whatever storage it was started with — silently bypassing the Remote Cache (this exact hijack corrupted the first measurement attempt).

What

• The proxy serves the webdav write surface: MKCOL always succeeds (collections are virtual — the Remote Cache is a flat object store), PROPFIND answers directory-shaped paths as existing collections and object paths from artifact_exists, with the minimal multistatus body opendal's parser requires. Routing moved to a single method dispatcher (also fixes the unmatched root path /).
• SCCACHE_SERVER_PORT is injected alongside the other wrapper env, derived per repository in a range disjoint from the proxy's.
• Root turbo.json joins the native-lib CI path filter, so future-flag changes run js_native_packages — the job that exercises Cargo tasks (the dogfood PR's job was silently skipped without this).

How

Regression coverage now goes through the genuine article: a dev-dep on opendal 0.55 (sccache's exact webdav client version) doing the probe-write/fan-out-key write/read cycle against the proxy + mock API. That test fails on the old router with the exact production error (missing field getlastmodified → storage init failure).

Measured locally (M-series macOS, debug-build turbo as the wrapper, production Remote Cache) on a 430-crate cold build, cargo clean between runs, --force — CI cannot produce these numbers until this ships in a canary, since PR runs use placeholder credentials by design:

	wall	compile cache
populate	107s	406 misses stored, 0 write errors
rebuild	42s	406/406 hits (100%)

~2.5x — with an unoptimized debug turbo as the wrapper; release binaries in CI should do better. The rebuild also validated endpoint stability: its wrapper invocations were served by the persistent server spawned in the first run.

First GitHub-Actions-visible verification will be consecutive push-to-main runs of js_native_packages once this is in the canary the dogfood PR (#13292) runs on: look for sccache compile cache proxy listening in the logs and compare turborepo-napi#build wall time across runs.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
examples-basic-web	Ready	Preview, Comment, Open in v0	Jul 7, 2026 1:41am
examples-designsystem-docs	Ready	Preview, Comment, Open in v0	Jul 7, 2026 1:41am
examples-gatsby-web	Ready	Preview, Comment, Open in v0	Jul 7, 2026 1:41am
examples-kitchensink-blog	Ready	Preview, Comment, Open in v0	Jul 7, 2026 1:41am
examples-nonmonorepo	Ready	Preview, Comment, Open in v0	Jul 7, 2026 1:41am
examples-svelte-web	Ready	Preview, Comment, Open in v0	Jul 7, 2026 1:41am
examples-tailwind-web	Ready	Preview, Comment, Open in v0	Jul 7, 2026 1:41am
examples-vite-web	Ready	Preview, Comment, Open in v0	Jul 7, 2026 1:41am
turbo-site	Ready	Preview, Comment, Open in v0	Jul 7, 2026 1:41am