Daniele
e0d75a8dc8
Nightly Build / build (push) Canceled after 6m16s
Cargo decides freshness by mtime, and the Gitea runner deletes the job workspace after each run. So `actions/checkout` stamped every source file with "now" and all 20 workspace crates recompiled regardless of what the commit touched: measured on a JS-only commit, 20 of 722 rlibs rebuilt — the ~700 third-party deps stayed cached, our own code never did. That, not the size of skald-core, was the 4 minutes per architecture. Restore mtimes from git history after checkout (needs the full history, hence fetch-depth: 0 — cheap here, ~170 commits against a Gitea instance on the same machine). Also: - nightly: CARGO_INCREMENTAL=1. Release builds have incremental off by default, the worst case for a 51k-line crate. The nightly trades a marginally less optimised binary for the rebuild time; release does not. - nightly: concurrency with cancel-in-progress. The runner has capacity 1 and the nightly publishes to a fixed filename, so a queued build was 8 minutes spent on a tarball the next one overwrites. - release: its own CARGO_TARGET_DIR. CARGO_INCREMENTAL is part of cargo's profile fingerprint, so one shared cache between a workflow that sets it and one that does not would have each invalidate the other's workspace crates — reintroducing the very rebuild this removes. - packaging steps derive --target-dir from $CARGO_TARGET_DIR instead of repeating the path, so the two cannot drift.