ci(maestro): cache nix store, trim CI hot paths
ci / web (pull_request) Successful in 40s
ci / flake (pull_request) Successful in 3m58s
ci / rust (pull_request) Successful in 4m36s

The `flake` job was the pipeline's critical path at ~9 minutes, all of it
one cold `nix build`: with an empty /nix every run, it recompiled the whole
release closure under `lto = "thin"` + `codegen-units = 1`.

- Cache /nix across runs, keyed on the lockfiles the closure derives from,
  so crane's deps-only derivation survives and only maestro's own crates
  rebuild. Saved from pushes only, so a PR cannot write a partial store.
- Build only `.#webFrontend` on PRs — that is the step that guards
  pnpmDeps.hash. The release binaries stay on main.
- Replace the hand-rolled `target/` cache with Swatinem/rust-cache, which
  prunes to the current lockfile instead of accumulating stale artifacts
  behind a prefix restore-key. ~60s per run went into moving that entry.
- Run tests under cargo-nextest, which parallelises across the 20
  integration binaries. Capped at 4 threads in .config/nextest.toml: the
  tmux-backed tests starve each other at the num-cpus default and trip
  their 5s deadlines.
- actions/setup-node instead of a second apt-get pass via nodesource.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Miguel Palhas
2026-09-02 17:48:32 +01:00
co-authored by Claude Opus 5
parent 63191c7be1
commit 64d5829037
2 changed files with 122 additions and 21 deletions
+20
View File
@@ -0,0 +1,20 @@
# The integration suites drive real tmux servers and real git repos, and most
# of their wall time is spent waiting on those subprocesses rather than on the
# CPU. nextest runs test binaries in parallel — which plain `cargo test` does
# not — but at its `num-cpus` default the tmux-backed tests starve each other
# and the tighter `wait_for_async` deadlines (5s) start timing out. Capping the
# concurrency keeps the cross-binary win without the contention.
[profile.ci]
test-threads = 4
# Anything past this is reported as slow while it keeps running, so a genuine
# hang is visible in the log instead of only showing up as a job timeout.
slow-timeout = { period = "30s", terminate-after = 8 }
failure-output = "immediate-final"
final-status-level = "slow"
# nextest does not run doctests. There are none today (every ``` fence in the
# crates is `toml` or `text`), so nothing is lost; adding a real doctest means
# adding `cargo test --doc` to CI alongside this.