Files
Dario Gabriel LipicarandClaude Opus 5 a257d9e422 ci: keep reading the old Cachix until the Attic caches are seeded
The previous commit broke CI on main here, and the mechanism is worth recording.
Measured, by asking each cache for the path that failed in keystore-module
(the same class of path fails in every Rust-building repo):

  logos-co.cachix.org           200  <- present
  cache.nix.logos.co/public     404
  cache.nix.logos.co/ci         404
  cache.nixos.org               404

The failing path is a fixed-output fetch of a crates.io tarball
(crate-alloy-eip7928-0.3.4.tar.gz). With Cachix in the substituters CI never
performed that fetch -- it downloaded the finished path. Dropping Cachix
therefore did not merely cost cache hits: it made CI attempt the fetch for the
first time, and it fails there in ~7 minutes, taking cargo-vendor-dir and the
whole module with it.

The crate itself is healthy: that URL returns 20373 bytes hashing to
407510740da5..., exactly the expected outputHash. So this is not a yanked crate
or a stale hash -- it is an untested assumption ("CI can fetch from crates.io")
that Cachix had been hiding.

Cachix therefore stays as a READ-ONLY substituter until Attic has the paths. It
is credential-free (the cache is public) and nothing publishes to it any more:
pushes go to Attic, public on main and ci elsewhere. Drop these two lines once
Attic is seeded -- and expect that first uncached build to exercise the fetch
path for real.

The Attic side is confirmed working in the failing runs themselves: they
substituted python3-env and doctest from cache.nix.logos.co/public, and the push
step correctly skipped, since these repos have no public-cache environment yet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-27 00:44:12 -03:00
..