client: implement client-side compilation mode#2675
client: implement client-side compilation mode#2675sylvestre wants to merge 11 commits intomozilla:mainfrom
Conversation
Add Serialize, Deserialize, and Debug derives to FileObjectSource so it can be used in protocol request/response types for client-side compilation.
Change the storage parameter from Arc<dyn Storage> to Option<Arc<dyn Storage>> in the CompilerHasher trait and all implementations (C/C++, Rust). This allows client-side compilation to call generate_hash_key without needing a storage instance.
Add protocol types for the client-side compilation model where the server acts as a pure cache store: - CacheGetRequest/CacheGetResponse: look up cache entries by key, with output paths for the server to extract artifacts directly to disk (shared-filesystem model, no large IPC transfers) - CachePutRequest/CachePutResponse: store compilation results - PreprocessorCacheGet/PreprocessorCachePut: preprocessor cache ops
Implement server-side handlers for the client-side compilation protocol: - handle_cache_get: extract cached artifacts directly to client paths - handle_cache_put: read artifacts from client paths and store in cache - handle_preprocessor_cache_get/put: preprocessor cache operations - validate_output_paths: reject non-absolute paths and .. components to prevent path traversal attacks - Increase default max frame length to 512 MB for large cache entries
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2675 +/- ##
==========================================
+ Coverage 74.17% 74.43% +0.26%
==========================================
Files 70 70
Lines 39207 39669 +462
==========================================
+ Hits 29083 29529 +446
- Misses 10124 10140 +16 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
When SCCACHE_CLIENT_SIDE_COMPILE=1, the client performs all compilation work (compiler detection, preprocessing, hash generation, compilation) and uses the server as a pure cache store via CacheGet/CachePut. The do_compile_client_side function: 1. Detects the compiler and parses arguments 2. Runs the preprocessor locally and computes the cache key 3. Sends CacheGet to the server 4. On hit: uses cached artifacts (already extracted by server) 5. On miss: compiles locally, sends CachePut to store the result
871118e to
e4a5118
Compare
Add #[serial] and explicitly set SCCACHE_CLIENT_SIDE_COMPILE=0 in tests that exercise the server-side compilation path, so they pass regardless of the environment.
Add CI matrix entries that run the test suite with client-side compilation enabled (SCCACHE_CLIENT_SIDE_COMPILE=1) on Ubuntu, macOS, and Windows to ensure both compilation modes are tested.
- Rewrite Architecture.md with sequence diagrams for both compilation modes, comparison table, cache key generation docs, and protocol docs - Add SCCACHE_CLIENT_SIDE_COMPILE to Configuration.md - Add compilation modes section to README.md - Fix pre-commit clippy to use explicit features instead of --all-features
…_paths Add unit tests for validate_output_paths (absolute, relative, dotdot, empty, multiple paths) and client-side stats display. Add integration tests that exercise the CacheGet/CachePut protocol round-trip through a real server: miss → put → hit, path validation rejection, and missing file handling.
Huh, I haven't even looked at the implementation, but this is a huge red flag. This shouldn't be changing anything about preprocessing. The preprocessing part is a very important part of how sccache works and it can't be skipped except in direct mode, but that wouldn't be a difference between the server mode and the client mode anyways. Direct mode, by the way, does not appear in neither graph. |
Instead of running the compilation in the server, it is done on the client level.
I had 2 digits per improvements on Firefox