Skip to content

Fix use of the iohk binary cache

Jean-Paul Calderone requested to merge iohk-cache-debugging into main

Jobs stopped using the iohk cache, probably in October, with this error:

warning: unable to download 'https://hydra.iohk.io/nix-cache-info': SSL peer certificate or SSH remote key was not OK (60); retrying in ...

hydra.iohk.io uses a Let's Encrypt certificate so this error is probably caused by the ~3 year old image we were using lacking the "ISRG Root X1" in its trust roots. The older CA certificate "DST Root CA X3" expired in October 2021.

The nixos image previous used is marked as deprecated on Docker Hub and hasn't been updated in some time.

The nixos image used elsewhere (eg in ZKAPAuthorizer) doesn't use bash so switching to it breaks the way we supply configuration to nix. This is enough to prevent it from using the iohk cache, too, so this PR also changes the way we supply that configuration.

I tested several intermediate revisions of this branch to make sure they would actually fetch objects from the iohk cache when needed for the build and available from that cache. "Warm" build time (no CircleCI cache but good objects in iohk and saxtons) is around 10m20s, much of which is spent downloading objects from caches. I left the CircleCI cache configured because downloading from it is much, much faster. "Hot" build time (with a populated CircleCI cache) is around 2m.

I'm still mystified by the whole CircleCI cache key system. Their docs on "partial cache restore" read like word salad to me. So I've left the very simple sources.json checksum-based key rather than trying to add more layers.

Merge request reports