Caching a custom package set with Hydra

Development
1

Hi all!

I have a package set that I work on here: GitHub - cprussin/nixjs: A nix overlay containing a collection of node versions and associated tools. I’ve been interested in getting the packages to be cached in a binary cache somewhere to speed up build times for folks who consume the package set (it takes around an hour on a fairly beefy machine to compile either of nodejs or purescript). I posted a thread about this a while back and someone recommended the cachenix project, which is interesting but doesn’t quite solve my needs (I haven’t found a good way to trigger the builds from CI since they take too long for travis, and in any case the cache becomes stale when the upstream nixpkgs get updated). I think that building the package set in Hydra alongside nixpkgs would be ideal, but I don’t know if this is possible for a custom (non-nixpkgs) project. Is this possible? Does anyone have any pointers here to help me get started?

Thanks!

2

How about Cachix?

1 Like
3

Yeah, I took a look at it a while back, it is interesting but doesn’t quite solve my needs (I haven’t found a good way to trigger the builds from CI since they take too long for travis, and in any case the cache becomes stale when the upstream nixpkgs get updated). I think that building the package set in Hydra alongside nixpkgs would be ideal.

What I want to solve for is:

  1. CI integration (there are a few combinations in the package set and the builds are fairly slow, too slow for open-source travis).
  2. Rebuilds on nixpkgs upgrades. I’m sure there’s some way to make most CI tools react to a nixpkgs upgrade, but I don’t know what it is.

I think that I could get hydra to solve both of these, and it seems like the mosty nixy way of doing build caching. So I’m most interested in that, but any other ways to solve this would be great as well!

1 Like