Feature a NixOS Image

[Malix-Labs]

Nix is a purely functional package manager and build system which is increasingly used in GitHub Actions and Workflows.

Its package collection, nixpkgs, is also the most comprehensive in the world BY FAR:

It also is gaining exponential popularity over the years and has arguably recently reached escape velocity for building, packaging, and configuring software:

Featuring Nix in another standard image such as ubuntu ones has already been requested:

• Add nix package manager #376
• Add Nix package manager #1579
• Update/Add nix package manager #7066

However, it does not solve the fundamental issue with using Nix in standard runners:
The bloat from pre-installed (and thus unusable) software makes Nix otfen run out of space

We can verify this using https://github.com/Malix-Labs/GitHub-Action_Runner-Fetch/actions/workflows/fetch.yml

A few projects work around this, including generic ones but also more specialized ones for Nix:

• https://github.com/wimpysworld/nothing-but-nix
• https://github.com/Malix-Labs/GitHub-Action_Nix-Reclaim (my own project, which was the main motivation for me to create this issue in the first place)

But! something architecturally more correct would be to feature a dedicated NixOS image so that the whole runner would be optimized

This would end up not only fixing the storage issue when using Nix in GitHub Actions, but also being probably more efficient for both GitHub and GitHub Actions users.

[v-davit-ioramashvili]

Hi,

We will take a look.

[cafkafk]

If there is anything the NixOS foundation can help with, let me know and I'll make sure to get it discussed with the board or relevant teams.

This would be an amazing addition. :)

[Eveeifyeve]

I am happy to get the ball rolling when I am back from LOA, which is in a couple hours. Since I find this useful to intergrate NixOS into existing business workflows with GHA.

[auscyber]

architecturally as well it would make sense to include nixpkgs unstable or the latest stable at minimum loaded into the evaluation cache, along with some base packages already downloaded such as npm, rustc, some c compilers to decrease build times for common workloads. on the current images, loading nixpkgs into the evaluation cache can take a minute or so and consume a lot of compute time at the start of every build of any sort

[Malix-Labs]

Context for people not familiar with Nix/NixOS/Nixpkgs:

• unstable is the rolling release version. APIs are allowed to change which is why it has been named "unstable", but the architecture of Nix makes it more robust than the usual imperative (non-nix) distribution's stable versions. It is used by most of the userbase and quasi everywhere in the ecosystem (i.e. third-party flakes, …). Its name should not discourage its integration.

• Feature a NixOS Image #14558 (comment) from @auscyber:

  npm, rustc, some c compilers

  This is referring to npm, rustc, and some c compilers from Nixpkgs and be put in the Nix store

• Nixpkgs is split between two main ways of consumptions:

  • Channels: Imperative subscriptions to nixpkgs branches (similar to adding a PPA or tracking an apt repo). Often used with ad-hoc pinning for reproducibility.
  • Flakes: Hermetic dependency management with a lockfile (flake.lock). "experimental" (but mature since a few years, and popular since 78.9% of the community uses them) and so gated behind a flag.

---

include nixpkgs unstable or the latest stable at minimum loaded into the evaluation cache, along with some base packages already downloaded such as npm, rustc, some c compilers

Including the latest unstable (nixos-unstable for NixOS) or the latest stable (currently nixos-26.05) would make sense since it is how the base operating system would be updated;
But from that point on, most users should/would use a pinned version of nixpkgs (for reproducibility) in a way or another.
Thus, I'm not sure that "including npm, rustc, and some c compilers from nixpkgs" into the nix store by default makes sense since their exact version would most probably not be used (even if garbage collecting installed packages is trivial in Nix).

[Eveeifyeve]

architecturally as well it would make sense to include nixpkgs unstable or the latest stable at minimum loaded into the evaluation cache, along with some base packages already downloaded such as npm, rustc, some c compilers to decrease build times for common workloads. on the current images, loading nixpkgs into the evaluation cache can take a minute or so and consume a lot of compute time at the start of every build of any sort

Architecturally loading rustc, npm and some c compilers actually doesn't help as malix explained. But what will help is using the official cache set in the substitute settings and using the exact rev that the official channels are up to.

[Malix-Labs]

https://cache.nixos.org is already a default substituter (i.e. you can check it here)

There would of course need some added wiring to make it compatible with GitHub Actions Runners,
But further than this point,
I am arguing the image should be as simple, as close to a vanilla NixOS from Hydra with sudo permission, as possible (not even experimental features, they can later be toggled on by users if needed)