public/soundy-bits

Fork 0

ci: warm the dynamic build via a persistent CARGO_TARGET_DIR (drop rust-cache) #21

Merged

psk merged 1 commit from ci/cache-dynamic-dylib into master

2026-06-30 21:33:13 +00:00

psk commented

2026-06-30 21:11:25 +00:00

Owner

Why

Every PR/release build gate spends 10+ min "just getting started." actions/checkout's clean:true wipes the in-workspace target/ each run, so Swatinem/rust-cache tar/untars the dependency artifacts — including the ~1.1 GB --features dynamic libbevy_dylib.so — through Forgejo's cache backend on every run (and a blob that size can exceed the backend's per-entry cap and get dropped, rebuilding cold anyway).

What

On a single persistent native runner you don't need a cache backend: point CARGO_TARGET_DIR at a persistent path outside the cleaned workspace and let cargo's own on-disk fingerprinting decide rebuilds. Deps (incl. the dylib) are reused from real disk; only the changed local crate + tests recompile — exactly like local dev. (The "raw target/ mtime invalidation" worry is a tar-cache failure mode; nothing is tarred here.)

rust-toolchain.toml — pin 1.96.0 + clippy + wasm, so the cache only cold-rebuilds on a deliberate toolchain/Cargo.lock bump, not a runner-side rustup update.
ci.yml + release.yml build-and-test — route CARGO_TARGET_DIR=$HOME/.cache/soundy-bits-ci/target (same path → the release gate is pre-warmed by PR runs) + a self-bounding 40 G disk guard; drop the now-redundant rust-cache step. Added rust-toolchain.toml to the CI paths filter.
Heavy release matrix keeps rust-cache — its per-target CARGO_TARGET_DIR builds (nvenc/cross/headless) weren't migrated to the persistent-dir scheme.
Reworded two now-stale rust-cache cross-references.

Note on the first run

The first CI run on this PR is cold — it populates the persistent dir. Subsequent runs reuse it; push a trivial follow-up commit to watch the warm path skip the Bevy/dylib compile.

🤖 Generated with Claude Code

## Why Every PR/release build gate spends 10+ min "just getting started." `actions/checkout`'s `clean:true` wipes the in-workspace `target/` each run, so `Swatinem/rust-cache` tar/untars the dependency artifacts — including the **~1.1 GB `--features dynamic` `libbevy_dylib.so`** — through Forgejo's cache backend on every run (and a blob that size can exceed the backend's per-entry cap and get dropped, rebuilding cold anyway). ## What On a single **persistent native runner** you don't need a cache *backend*: point `CARGO_TARGET_DIR` at a persistent path **outside** the cleaned workspace and let cargo's own on-disk fingerprinting decide rebuilds. Deps (incl. the dylib) are reused from real disk; only the changed local crate + tests recompile — exactly like local dev. (The "raw `target/` mtime invalidation" worry is a *tar-cache* failure mode; nothing is tarred here.) - **`rust-toolchain.toml`** — pin `1.96.0` + clippy + wasm, so the cache only cold-rebuilds on a **deliberate** toolchain/`Cargo.lock` bump, not a runner-side `rustup update`. - **`ci.yml` + `release.yml` `build-and-test`** — route `CARGO_TARGET_DIR=$HOME/.cache/soundy-bits-ci/target` (same path → the release gate is pre-warmed by PR runs) + a self-bounding 40 G disk guard; drop the now-redundant `rust-cache` step. Added `rust-toolchain.toml` to the CI paths filter. - **Heavy `release` matrix keeps `rust-cache`** — its per-target `CARGO_TARGET_DIR` builds (nvenc/cross/headless) weren't migrated to the persistent-dir scheme. - Reworded two now-stale rust-cache cross-references. ## Note on the first run The **first** CI run on this PR is **cold** — it populates the persistent dir. Subsequent runs reuse it; push a trivial follow-up commit to watch the warm path skip the Bevy/dylib compile. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

psk added 1 commit

2026-06-30 21:11:25 +00:00

ci: warm the dynamic build via a persistent CARGO_TARGET_DIR (drop rust-cache)

ci / build-and-test (pull_request) Successful in 1m22s

Details

a1ee958c8d

The PR/release build gates spent 10+ min re-materializing target/ each run:
checkout's clean:true wipes the in-workspace target/, so rust-cache tar/untars
the dependency artifacts — incl. the ~1.1GB --features dynamic bevy_dylib.so —
through Forgejo's cache backend every run.

The runner is a single persistent native host, so route CARGO_TARGET_DIR to
$HOME/.cache/soundy-bits-ci/target (outside the cleaned workspace) and let
cargo's own on-disk fingerprinting decide rebuilds. Deps (incl. the dylib) are
reused from real disk; only the changed local crate + tests recompile. Pin the
toolchain (rust-toolchain.toml) so the cache only cold-rebuilds on a deliberate
bump, and self-prune the dir at ~40G. The heavy release matrix keeps rust-cache.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

psk force-pushed ci/cache-dynamic-dylib from a1ee958c8d

ci / build-and-test (pull_request) Successful in 1m22s

Details

to 148f5c953e

ci / build-and-test (pull_request) Successful in 1m22s

Details

ci / commit-lint (pull_request) Successful in 2s

Details

2026-06-30 21:31:10 +00:00

Compare

psk merged commit 6af3769dae into master

2026-06-30 21:33:13 +00:00

psk deleted branch ci/cache-dynamic-dylib

2026-06-30 21:33:13 +00:00

psk referenced this pull request from a commit

2026-06-30 21:33:15 +00:00

Merge pull request 'ci: warm the dynamic build via a persistent CARGO_TARGET_DIR (drop rust-cache)' (#21) from ci/cache-dynamic-dylib into master

No reviewers

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

public/soundy-bits!21

No description provided.

Rows
Columns