Open ParetoOptimalDev opened 1 year ago
I think? I can't say for sure if that technically maps to the end result I described above, but I'm pretty sure it does.
It looks like the creator of nix-eval-jobs also has nix-ci-build which seems very similar to nixci.
It looks like the creator of nix-eval-jobs also has nix-ci-build which seems very similar to nixci.
Interesting, seems to be have been created 5 days ago.
This is problematic,
For each flake attribute, a separate nix-build process is spawned.
For projects that use IFD (https://github.com/nammayatri/nammayatri) and has gazillion package outputs, this will cause repeat evaluation unnecessarily, which is what devour-flake mainly solves.
But I'll play with it to see if there's anything nixci can adopt.
cc @ipetkov
But I'll play with it to see if there's anything nixci can adopt.
If it helps I'm currently testing it out here so build time differences can be seen:
https://github.com/ParetoOptimalDev/haskell-template2/actions
It's faster, but I think right now it may not be an accurate comparison because it's not building as much. I'm not for sure though.
Oh, related to the above I found:
https://github.com/Mic92/nix-fast-build
I asked them to compare to nixci, so I'm sure you want to look over the comparison to ensure it is accurate:
Thanks, will take a look once I get a chance. It looks like I must be missing something important, and if so that could be an opportunity to improve nixci itself.
overall goal: No nix builds happen if already cached, so editing Readme.md for instance would mean actions finishes in <30s.
nix-build-uncached used to allow this. Then it became nix-eval-jobs.
Now I think there might be some way in flakes that covers this functionality, at least I remember @domenkozar mentioning it somewhere.
Is it possible for nixci to support this? That was my main reason for experimenting with #28 .