Snix's nar-bridge[1] stores NARs under a different URL, i.e. `nar/snix-castore/<hash>.nar` rather than `nar/<filehash>.nar`. Right now, when copying into such a store via the http binary-cache, we'd end up with wrong cache entries that point to the wrong NAR URL. On Hydra, this is a fatal error, i.e. builds that depend on previously built paths (that were written to the cache before by the queue runner) would be aborted because of that. This patch removes the caching since we'd have to re-fetch the narinfo to do taht and this can also happen the next time, the narinfo is queried. Also, removes the negative cache entry indicating that the store-path doesn't exist in the store. We don't have any coverage for http-stores so far, so I wrote a small testcase for the "default" case and the nar-bridge case in functional2 since it has a very nice fixture for an HTTP server ready. I'm aware that there's a CL for a nicer cache server[2], but given I'm down a pretty deep rabbit hole by playing around with Snix, I decided to not finish the CL and write something small for the tests in here. This can be replaced by the fixtures from that CL later on as well. [1] https://snix.dev/docs/components/overview/#nar-bridge [2] https://gerrit.lix.systems/c/lix/+/2431/1 Change-Id: I4fcdf47a6bf9c3c8fbeb235eeca7a48914a4d693
635 B
635 B
synopsis, issues, cls, category, credits
| synopsis | issues | cls | category | credits | ||
|---|---|---|---|---|---|---|
| libstore/binary-cache-store: don't cache narinfo on nix copy, remove negative entry |
|
Fixes |
|
When using e.g. Snix's nar-bridge via
an http-store, Lix would create cache entries with a wrong URL to the NAR when uploading
a store-path.
This caused hard build failures for Hydra.
Lix doesn't create these entries on upload anymore. Instead, it only removes negative cache entries. The cache entry for a narinfo is now created the first time, Lix queries the cache for the previously uploaded store-path again.