A file's mtime is unique, so cargo's freshness record is stable - #77
Merged
Conversation
Cargo records a path dependency's freshness as the newest mtime in the
package and the name of the file that carried it. Dating files by their
last commit gives every file a commit touched the same timestamp, so
which one is newest falls to directory order — which differs between
clones. The gate rebuilt iroh, iroh-dns, iroh-relay and iroh-peer on
every run, reporting
PrecalculatedComponentsChanged {
old: "1784575660.000000000s (Cargo.toml)",
new: "1784575660.000000000s (CHANGELOG.md)" }
the same instant, a different file. Each file now takes a sub-second
offset derived from its path, so one file is newest and every clone
agrees which.
The stamping policy joins the build-directory cache key: artifacts are
kept or discarded on the strength of the mtimes they were judged
against, so a change to how those are assigned invalidates them.
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
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.
What
Each file's restored mtime takes a sub-second offset derived from its path, and
scripts/restore-mtimes.pyjoins the build-directory cache key.Why
#76 measured a steady gate of 3m12 with nothing compiled. On main it settled at 4m52 with eight units rebuilding every run —
iroh,iroh-dns×3,iroh-relay×3,iroh-peer— from an exact-key cache hit. The branch's clean run was luck.Cargo records a path dependency's freshness as the newest mtime in the package and the name of the file that carried it. A commit that touches several files gives them all one timestamp, so which file is newest is decided by directory order, which differs between clones. Running the gate under fingerprint logging (probe run 31740876568) names it exactly:
Same instant, different file. A path-derived nanosecond offset makes one file strictly newest, and every clone agrees which. Verified locally: every package under
.deps/irohnow has exactly one newest file (iroh-dnspreviously tiedCargo.tomlwithCHANGELOG.md, precisely as cargo reported).Measured
Seeded, then two consecutive runs on this branch — each re-clones
.deps, so each walks a differently ordered directory:Against 4m52 with eight rebuilds on main today.
just checkpasses; this PR's own run is the gate.Notes
scripts/restore-mtimes.py: artifacts are kept on the strength of the mtimes they were judged fresh against, so changing how those are assigned must invalidate them. Removing the temporary branch allowlist used for the measurement changesci.yml, which is in the key too — so the first run on main restores the newest entry under the prefix (not cold), rebuilds those units once, and saves. The run after that is the steady state above.