ci(nightly): preserve settings on local cache fallback
The nightly Release fallback now keeps the shared prefix-mapping and diagnostic settings when it drops only the fleet CAS/plugin/remote settings. This preserves incremental cache keys and hit telemetry on the local retry while still removing the unavailable fleet backend.
Leo said, βit feels like you guys always forget about incremental builds and the external SSDs.β This follows the exact-head review of #30107 and resolves the remaining part of #30106 after #30128 aligned the warmer and PR Release settings.
The executable regression runs both the fleet-backed attempt and the local retry, asserting the mapping/diagnostic settings remain while CAS/plugin/remote settings disappear from the retry.
Validation:
python3 -m unittest tests/test_ci_fleet_compilation_cache.py(9 tests)bash tests/test_ci_fleet_compilation_cache.shpython3 scripts/cmux-next/prepush-gate.py
Closes #30106.
Agent session: agent session
π€ Generated with Claude Code
![View with [code]smith](https://pr-comments-assets.blacksmith.sh/codesmith/view-with-codesmith-dark-v3-3x.png)
![Autofix with [code]smith](https://pr-comments-assets.blacksmith.sh/codesmith/autofix-with-codesmith-dark-3x.png)
Need help on this PR? Tag @codesmith-bot with what you need.
Summary by cubic
The nightly Release build now retries once with the local cache when the managed fleet CAS fails at runtime, instead of failing the job outright. The retry filters out only the fleet CAS/plugin/remote settings, keeping the shared prefix-mapping and diagnostic settings so incremental cache keys and hit telemetry stay intact.
- The retry triggers only on real runtime CAS diagnostics (
CAS error,remote service unavailable,cache plugin failed); source errors that merely mention "CAS" or "cache" still fail without a second build. - Tests assert the fleet-backed attempt keeps the CAS/plugin/remote settings while the local retry drops them, preserving the prefix-mapping and diagnostic settings.
- Closes #30106.