GRM as the basis of a declarative CI system

[colemickens]

Hi,

I'm playing around with some ideas for how to deal with Nix CI. In many nix monorepos, users have needs to rebase dependencies and then evaluate their repo with their updated dependencies. In some cases, this will involve multiple branches of a repo.

Rather trying to write some sort of script to manage checking out git repos and rebasing them -- well, it seems like that data is redundant with the data that GRM will have.

So I'm imagining a CI system that takes jobs in the form:

• nix expressions to evaluate
• GRM config
• a list of GRM directories, in order, to be updated/rebased, tag with a special suffixed tag (the build ID/date/ etc), pushed

Then the executor can:

• eval nix expressions as-is, save metadata, build them
• use GRM to instantiate a tree of source repos
• use GRM (or some tool that uses GRM as a lib) to process the list of input checkouts
• use GRM to tag those checkouts and push them
• use Nix to override it's "flake" inputs to the tagged branches
• eval nix expressions, save new metadata, build them again
• if successful, the build flake.lock encodes exactly what was built

Anyway, this has been bouncing around in my head, but unfortunately I'm blocked a bit by the nightly build issue before I can dive in to GRM and see if it will work for this purpose.