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 |
Replace `executor.hydra.jobset` (string) with `jobsets` (list of strings). Each tick the executor walks the configured jobsets in order and returns the first finished-success build of the current commit. This handles the common case where production and testing branches are evaluated by different Hydra jobsets — the user lists both, and whichever jobset built the commit is the one comin uses. A finished failure in any jobset is treated as authoritative and short- circuits without falling through; only "no match" or "still building" permits scanning subsequent jobsets. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
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. |
Replace the `executor.hydra.jobsets` (list of strings) added in the previous commit with a single jobset derived at eval time from the branch being deployed: `jobset_prefix` is prepended to the selected branch name (so branch "main" with prefix "nixos-" scans jobset "nixos-main"). This matches the common Hydra convention of naming jobsets after branches, and avoids making users enumerate jobsets by hand. To do this, thread the selected branch name through the Executor.Eval interface (it was available on the Generation but not forwarded). The nix, nix-flake and garnix executors accept and ignore the new argument. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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