feat(publish): sweep artifacts the lockfile no longer references before snapshotting — a dependency bump doubled zemyna's dev target #23

New Issue

2026-09-08T03:49:48Z

claude commented

2026-09-08 03:49:48 +00:00

Symptom

After zemyna bumped Bevy 0.19.0 → 0.19.1 (zemyna PR #1045), the dev target on gitdan-ci grew from ~40 G to 66 G: the 0.19.1 objects were compiled beside the still-present 0.19.0 ones, because the target is seeded by hardlink-cloning the previous snapshot and nothing removes artifacts the new lockfile no longer references. The publish step then needs a private copy of the (now larger) mutable set, and on a 193 G disk with the old snapshot (46 G) still present it failed with No space left on device (zemyna run 3507, twice on 2026-09-07). Every future clone from that snapshot carries the dead objects too.

Scope

Before cargo-cache-publish stages a snapshot, sweep artifacts not referenced by the current build: cargo sweep --installed/--file style (drop deps/ entries whose package-version is absent from Cargo.lock, and .fingerprint/build dirs older than the run's own watermark), or cargo clean -p <crate>@<old version> for every version present in the target but not in the lock. Measure the snapshot size before/after on a lockfile bump.
Reuse record-watermark.sh's timestamp to decide "stale": anything not touched by this run's build is a candidate.
Selftest: a fixture target with two versions of one crate, only one in the lock → the sweep removes the other and keeps everything referenced.

Acceptance criteria

A snapshot published after a dependency bump does not carry the previous version's objects (measured on the selftest fixture and stated for zemyna's next bump).
The sweep never removes an artifact the current lockfile references (selftest asserts).
README documents the sweep and its cost.

Source

zemyna run 3507 / PR #1045 (Bevy 0.19.1), 2026-09-07; see also #20 (headroom) — this is the other half of the disk pressure.

## Symptom After zemyna bumped Bevy 0.19.0 → 0.19.1 (zemyna PR #1045), the `dev` target on `gitdan-ci` grew from ~40 G to **66 G**: the 0.19.1 objects were compiled beside the still-present 0.19.0 ones, because the target is seeded by hardlink-cloning the previous snapshot and nothing removes artifacts the new lockfile no longer references. The publish step then needs a private copy of the (now larger) mutable set, and on a 193 G disk with the old snapshot (46 G) still present it failed with `No space left on device` (zemyna run 3507, twice on 2026-09-07). Every future clone from that snapshot carries the dead objects too. ## Scope - Before `cargo-cache-publish` stages a snapshot, sweep artifacts not referenced by the current build: `cargo sweep --installed`/`--file` style (drop `deps/` entries whose package-version is absent from `Cargo.lock`, and `.fingerprint`/`build` dirs older than the run's own watermark), or `cargo clean -p <crate>@<old version>` for every version present in the target but not in the lock. Measure the snapshot size before/after on a lockfile bump. - Reuse `record-watermark.sh`'s timestamp to decide "stale": anything not touched by this run's build is a candidate. - Selftest: a fixture target with two versions of one crate, only one in the lock → the sweep removes the other and keeps everything referenced. ## Acceptance criteria 1. A snapshot published after a dependency bump does not carry the previous version's objects (measured on the selftest fixture and stated for zemyna's next bump). 2. The sweep never removes an artifact the current lockfile references (selftest asserts). 3. README documents the sweep and its cost. ## Source zemyna run 3507 / PR #1045 (Bevy 0.19.1), 2026-09-07; see also #20 (headroom) — this is the other half of the disk pressure.

claude added the enhancement label 2026-09-08 03:49:48 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: daniel/gitdan-actions#23