enable cachix

[chris-martin]

This modifies the github workflow such that build results are pushed to cachix. It also modifies the flake such that users are directed to use the binary cache.

[chris-martin]

Some notes:

CI is passing for the first time in a long time. Since everything is cached, it doesn't actually do much of anything until something changes 😄 There are a few things that, if they have to actually get built on a GitHub Actions runner, don't actually work because the build runs out of disk space. This can can fixed by bumping the runner up to the 4-core version, but I'm going to see if we can get away with relying on the cache to avoid keeping it set to the bug runner permanently.

MacOS is currently disabled in the GH actions because there are a few packages that don't build on that platform (at least e.g. cypress). I think we just need to fiddle with the definitions of particular packages for which this is the case to avoid declaring support for platforms we can't actually support.

I also threw in a few new GHC versions to this PR.

A reminder that I'm going to keep repeating in various places: freckle-flakes is a public cache. Therefore:

• Do not push to this cache if you're in a private git repo; the entire repository contents will be uploaded!
• Do not ever use the cachix watch-store command
• If you use cachix watch-exec, make sure your cachix version is at least 1.7.

To build everything locally and upload it to the cache, after setting up your auth token you can run:

cachix watch-exec freckle-flakes -- nix flake check

The github action will also build everything and upload to the cache, but doing it locally is a nice option because when you make changes you may want to test them locally first anyway, in which case might as well just upload the artifacts instead of waiting for github to rebuild them redundantly. Alternatively, using the cache in the other direction is also a nice option: If you don't want to compile locally because you're low on disk space, battery, etc. then you can start by creating PR, wait for the build to finish, and then the artifacts will be there in the cache for you.

The compression that Cachix does seems to make a substantial difference; there's a lot of stuff here but Cachix is only reporting it as taking 2 GB.

[stackptr]

I saw cypress is not available for aarch64-darwin. I see that the CDN that fetchzip points to makes a version available for the platform, so there ought to be a way to work around this? In my testing, I get blocked by the alsa-lib dependency used in the Nix expression.

I'm curious if there is a way to cut out cypress and potentially other packages that prove problematic on macOS, in order to populate the binary cache with the other packages, rather than removing the macOS runner altogether? But I don't think that should block this improvement.

[stackptr]

Does cachix/cachix-action subsume the functionality of DeterminateSystems/magic-nix-cache-action in the CI workflow?

[chris-martin]

I'm curious if there is a way to cut out cypress and potentially other packages that prove problematic on macOS, in order to populate the binary cache with the other packages, rather than removing the macOS runner altogether?

Yeah, I don't think that'll be hard, I just don't immediately know how to write it. I suspect we'll want to refactor a little so that rather than applying eachDefaultSystem at the top level in flake.nix, maybe the definition for each package will either use eachDefaultSystem or provide definitions for a more limited list of systems.

Does cachix/cachix-action subsume the functionality of DeterminateSystems/magic-nix-cache-action in the CI workflow?

I think the idea is that magic-nix-cache-action allows us to make use of the github actions cache, and that cache restore ought to be faster than pulling from cachix. But I'm not really sure, and it's probably worth taking it out to see what difference it makes.