Add executor abstraction

[xinyangli]

This PR introduces a framework for CI integration, using Garnix as an example. It's still a proof of concept, though I am currently testing it on my machines.

Changes:

• Added executor option in config and NixOS module for CI specific options.
• Implemented evaluation and fetching of Garnix build results with minimal memory usage.
• Provide possibilities to integrate with other CI.

Known issues:

• machineId must be exported by CI after evaluation, otherwise we have to evaluate it on target machine. No easy solution found yet.

Related issue: #8

[nlewo]

Hello and congrats for this nice POC!

To be honest, i'm a bit afraid by having to maintain this Garnix executor mainly because i don't use Garnix. Moreoever, to test this feature, we would need to mock Garnix API which could evolve.

That being said, i think we could first introduce this executor abstraction without the Garnix part. Then, you could either maintain a fork for few months (in order to be sure you need this feature on the long term) or add an experimental flag when a user wants to enable this Garnix executor.

machineId must be exported by CI after evaluation, otherwise we have to evaluate it on target machine. No easy solution found yet.

Maybe we could add this value in the derivation itself. This would allow comin to read the derivation file to get some values. I don't know the proper way to do this but the comin module could set:

system.systemBuilderArgs.cominJSON = builtins.toJSON {machineId = "my-machine-id";};

The derivation produces by this NixOS configurations can then be used to get back the machineId value:

nix derivation show /nix/store/qn1w3xpsyknj6rmqy2c754jwmnw15sdn-nixos-system.drv | jq 'to_entries[] | .value.env |  .cominJSON'
"{\"machineId\":\"my-machine-id\"}"

Note, I'm planning to get more values from the evaluation (maybe tags/annotations to address this issue).

[xinyangli]

Thanks for the feedback! I totally get the maintenance concerns, and I agree—starting with the executor abstraction first makes sense. We can hold off on the Garnix part for now and maybe add an experimental flag later if needed. I will probably propose a more trivial executor later before the Garnix one (like fetching results from a existing file in a branch).

system.systemBuilderArgs.cominJSON = builtins.toJSON { machineId = "my-machine-id"; };

This is a extensible solution! I'll go with this.

Note, I'm planning to get more values from the evaluation (maybe tags/annotations to address this issue.

I also like this idea.

[xinyangli]

Removed Garnix builder for now.

[nlewo]

It would be really nice if you could open a draft PR with your Garnix executor in order to share it with comin users ;)

[xinyangli]

Updated accordingly! I've also removed the executor option from golang types. For Garnix executor, see #74