Add Garnix executor#74
Conversation
xinyangli
force-pushed
the
garnix-executor
branch
from
be89355 to
88e4f7c
Compare
xinyangli
force-pushed
the
garnix-executor
branch
2 times, most recently
from
aeb765d to
88e4f7c
Compare
xinyangli
force-pushed
the
garnix-executor
branch
8 times, most recently
from
80d7b19 to
116a559
Compare
xinyangli
force-pushed
the
garnix-executor
branch
from
116a559 to
f3b0403
Compare
- add `executor` option in config and nixos module - evaluate and fetch build result from garnix with minimal memory footprint - add test and doc for executors
Adds a Hydra CI executor parallel to the existing Garnix executor: delegates evaluation/build to a Hydra instance and fetches the result from its binary cache. Flake-based jobsets only for now; enforced via both Go config validation and a NixOS module assertion. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
@xinyangli nice to see you are still using this! FYI, I'm actually starting to investigate fetching storepaths from niks3. Instead of polling a git repository, i would like to poll the niks3 pinning API: https://github.com/Mic92/niks3/wiki/Pinning#deploying-systems-with-pins |
|
That looks very promising. I actually planned to try out niks3 but haven't had the time, so this gives me one more reason to :) I think it would take a pretty significant refactor to make it work as a fetcher though. With niks3's pinning approach, users wouldn't be able to fall back to evaluating and building locally, unless a specific naming scheme is required when pinning. I'd like to follow along as the fetcher refactor takes shape, and once the direction is clearer I can rebase this PR or look into adding more executors on top of it. |
2 participants
Add Garnix executor to fetch evaluation and build results from Garnix rather than running them locally. This is especially useful for low-memory machines.
Related: #69