test: share cargo target dirs per fixture family - #3268
Merged
Conversation
Isolated per-case target dirs meant every test case recompiled its whole dependency tree (~3100 rustc invocations per CI job, 55% uncacheable by sccache). Cases with compatible build configurations now share a per-family target dir (pyo3/cffi/uniffi/misc), so dependencies compile once and cargo's build lock serializes concurrent builds in a dir. Concurrent builds of *different* crates in one target dir are safe under cargo's lock, but maturin stages built artifacts under target/maturin/ (moving them out of cargo's output path and back), so concurrent builds of the *same* crate race on the staged files. Tests therefore take a per-fixture file lock around the build while different fixtures still run in parallel. The pyo3 config file maturin writes into target/maturin is now written via temp file + rename so concurrent builds sharing a target dir never observe a partial config. Cases keep an isolated target dir when they change compile flags (pgo, zig, explicit --target), build against unusual interpreters (conda, uv multi-python), or assert on target dir contents (pep517 profile checks, stable ABI selection). The develop test timeouts are raised from 120s to 600s since tests can now legitimately wait on the fixture lock. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NNNLg7XZnxM8Aiqrzo6c5q
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #3267 (see #2189): the remaining big lever for test time. Isolated per-case target dirs meant every test case recompiled its whole dependency tree — ~3100 rustc invocations per CI job, 55% of which sccache cannot cache (cdylib links, proc-macros, build scripts).
Design
shared-pyo3/shared-cffi/shared-uniffi/shared-misc), so dependency trees compile once per family. Cargo's own build lock makes concurrent builds of different crates in one dir safe, and artifacts for different feature sets coexist keyed by cargo's fingerprint.target/maturin/(renaming them out of cargo's output path and back), so two same-crate builds race on the staged files — reproduced locally with the develop + integration uniffi-proc-macro cases running concurrently. Tests therefore hold a per-fixturefs4file lock for the duration of the build (the same pattern the harness already uses for the cffi-provider venv). Different fixtures still build in parallel.--target), build against unusual interpreters (conda, uv multi-python), or assert on target dir contents (pep517 profile checks, stable-ABI selection which deletes the dir).src/hardening: the pyo3 config file maturin writes intotarget/maturin/is now written via temp file + rename so concurrent builds sharing a target dir never observe a partial config.Local measurements (full suite, cold state, no sccache, Apple Silicon)
test-crates/targetssize after runTotal CPU work drops ~44% with no wall-time regression and no lock starvation (the slowest single test got faster, 38.5s → 27.2s). A many-core dev machine hides main's redundant compiles behind parallelism; CI's 4-core runners are CPU-bound, so the CPU cut is what should translate to CI wall time there. CI won't see the full 44% since sccache already absorbs ~60% of compiles — this targets exactly the uncacheable remainder.
🤖 Generated with Claude Code
https://claude.ai/code/session_01NNNLg7XZnxM8Aiqrzo6c5q