[sentry-junior]

Both Rust jobs compile the full dependency tree from scratch on every run.

Rust tests (test_rust lane). The CI image only contains the release wheel, so cargo test rebuilds the test profile every time. In this run the build took 2m05s and the 191 tests ran in 2.8s.

The job now restores a dedicated target dir and bind-mounts it at rust_snuba/target inside the container:

• The cache is kept out of the image, so the other ~28 jobs that load snuba-ci don't download it.
• The key is the image's rustc commit hash plus Cargo.lock. On a Cargo.lock change, the job falls back to the newest cache for the same compiler.
• Only master saves, so PRs reuse master's dependency builds without churning the cache.

CARGO_INCREMENTAL=0 keeps the cached dir smaller. Incremental state doesn't help a fresh checkout.

Measured locally with the current master snuba-ci image (4 cores):

	test profile build	target dir
cold	2m35s	3.5 GB (786 MB zstd)
warm, all rust_snuba/src touched (like a fresh image)	13.7s

All 191 tests still run.

Clippy (Linting - Rust). Adds Swatinem/rust-cache (already used across getsentry/relay), saving on master only. Clippy spent about 113s compiling in this run.

protoc removed from Linting - Rust. setup-protoc without a pinned version queries GitHub for the latest 23.x release on every run. That lookup has failed jobs (1, 2). Nothing in rust_snuba/Cargo.lock runs protoc at build time: there's no prost-build, tonic-build, or protobuf-src, and sentry_protos ships generated code. I confirmed cargo check --workspace --all-targets --locked passes inside the CI image after deleting protoc. If you'd rather keep it, pinning version: "23.4" also avoids the lookup.

Cargo still evaluates the current checkout on every run; the cache only skips recompiling unchanged crates.

via Joshua Li.

--

View Junior Session in Sentry