(To try it out, run nix run github:srid/nixci in your project directory, after cachix use srid if you need the binary cache).
nixci enables you to build all of the flake outputs locally or somewhere in the CI. We use it in Jenkins, as well as on local development machines to build what CI builds but locally.
In addition, nixci supports building sub-flakes - which are written in a specific manner where the sub-flake refers to the parent flake. The sub-flake usually represents things like development environment and tests, things you don’t want to include in the top-level flake (so the user of that flake module do not inherit your dev/test flake inputs). Here’s an example where 3 sub-flakes are defined – example, test, dev – each of which are built by nixci.
First of all congratulations for the interesting (and useful) project
What is the overlap/difference between this and piping the output of nix-eval-jobs into something that continuously builds the derivations (I mean drv files) produced?
@acicerinixci is, ultimately, a wrapper around nix build -L <root>. At its most basic use, it scans for all buildable flake outputs and builds them (via having <root> drv take as input all those outputs; which is what devour-flake does). You can pass it a flake URL, a local path or a Github PR URL.
With nix-eval-jobs, AFAIU, you have to explicitly specify an attribute set of derivations to build and pass that to nix-eval-jobs. Even then, it only outputs the drvs, and you have to explicitly pipe and build them separately.
Plus, nixci can build sub-flakes, while overriding their input to point to the parent flake (or another subflake), which model is pretty handy for defining dev-only dependencies (see this project for an example, where we build dev env, tests, example - all as separate flakes, pointing to the root flake).
