I have pkgs.deno in my environment.systemPackages. After flake update (on unstable) when building the new configuration, it tries to compile deno and fails.
I wonder why it’s not read from cache - is it because it also fails on Hydra? How would I look this up? And how do you deal with these situations?
I would blindly assume it’s not in the cache as the build on hydra failed (like you guessed)
https://hydra.nixos.org/build/300138450
It seems that there are test failures.
Does your local build fail as well?
I have encountered this issue as well.
Local build fails after ~10 minutes or something on my system on the last compilation step.
Deno 2.3.6 is available. Maybe the version could be bumped in nixpkgs?
Besides deno, I’d be interested in how you handle broken packages in general. For deno I commented in out, but I wonder what to do for packages that I need everyday. The only thing I can think of is to find an older nixpkgs commit that still works and use that commit only for the broken package. What’s your approach here?
For me i am using the following setup.
I am using flakes, i have a github action that daily creates a PR for the flake update.
The hydra instance tries to build the result.
If its not buildable, the PR is kept open for analysis.
If its buildable it merges the PR after successful build and my machines can pull the changes.
So that means that machines dont update if there are build errors and they say on an older nixpkgs commit.
edit: i assume with something like npins a similar setup should work.
does your Hydra actually build everything, or does it also use the official Hydra’s cache?
It uses the official hydra cache as substitutor.
So it’s “just” building custom packages and everything that is to be build due to configuration (or overrides).
But according the threads situation it would have tried to build deno as well due to the cache miss (and failed with the same reason).
After that a attic cache is populated from which all my machines pull.
So for the machines, they should not have the need to build anything.
Depending on your closure sizes it should be possible to just build everything with GH-action and populate a cache afterwards. Cachix has some nice support for that. And you could automerge a PR after the action is successful.
In case you are interested in my current config it is available here.
Somewhere in the git history is also the setup for doing just GH Action.
I switched to a hydra setup when playing around with some global rebuilds for x86_64-v3, which was to much data for the action runner (atm I am not building any optimized binaries).