Open spacefrogg opened 7 years ago
I am using nix-1.12... and a hydra build new enough to demand that. Hydra triggers the above assertion when I try to download a build product that defines an explicit hydra-build-product
as doc manual <storepath>
adding a fourth field to specify the index.html does not mend the problem.
I am a bit out of luck researching the problem. Starting hydra in debug mode did not produce any valuable output. I couldn't figure out what parameters hydra-server hands off to nix to retrieve the build product or even where this happens.
The hydra instance is in production so I refrain from testing it with an older hydra-build that does not depend on nix-1.12. Maybe someone wants to check out that path. As both components are at play, here, either one of them could have introduced the problem.
I had the same symptom, in my case I ultimately tracked it down to this issue I reported over on the Nix repo where Nix-1.12 built with older Nix (presumably the normal upgrade path) results in Config.pm containing empty values for NIX_STORE_DIR and friends, which breaks things and results in the assertion you mention when calling some perl method like isValidPath.
I believe I used the following to check if my machine had a copy of Nix that was broken in this manner:
$ nix-instantiate --eval '<nix/config.nix>' -A nixStoreDir
Hope this helps!
Maybe this comes up due to a misconfiguration of my hydra instance, but packages built on remote machines are not available in the hydra-master's
/nix/store
but only in its binary cache.Build.pm
has logic built-in to retrieve a NAR in that case. So far so good. The web UI successfully shows that the build is available for download, but downloading it triggersin the server process. And the web UI shows the 404 page