Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid Nix evaluation on the target #8

Open
colemickens opened this issue Mar 4, 2024 · 2 comments
Open

Avoid Nix evaluation on the target #8

colemickens opened this issue Mar 4, 2024 · 2 comments

Comments

@colemickens
Copy link

Hi,

This looks very close to a tool I've been imagining in my head.

In my case, my CI (which is busted for other reasons), outputs it's built toplevels like this: https://github.com/colemickens/nixcfg/tree/3e5bf65bebeae617310a3624803d90d4abedc9ff/.latest

So, it would be nice to pass a path through to comin to tell it to just read an outPath rather than doing an eval. This would make comin more useful on really memory-starved targets that probably can't eval their own configuration.

@nlewo nlewo changed the title provide path to outPath rather than evaluating on target Avoid Nix evaluation on the target Mar 13, 2024
@nlewo
Copy link
Owner

nlewo commented Mar 13, 2024

@colemickens Thanks for this topic!

I find it really interesting, but i don't think I will start working/thinking on this soon.

For the record, this NixOS discourse comment proposes to use Git orphan branches to store built switch-to-configuration store paths.

@xinyangli
Copy link

Hi,

I'm really interested in this feature, so I implemented a demo on my fork. It's still a proof of concept at the moment.

The idea is that we can use different evaluation functions based on user config. The easiest would be constructing a url with user provided format string and querying that (optionally with hostname and/or commit id) for drvPath, outPath and machineId. We may also implement such function for hydra builds, which require us fetching the jobset first and then the evaluation result. Fetching and checking out a orphan branch through git is also possible, but I guess it will involve more work? This method will limit users to existing implementations, as it will probably require response from this url to have a specific format.

Another options is that we run a user defined external command to retrieve evaluation result, like what sshd do with AuthorizedKeysCommand. It would be more flexible, but I'm not sure if it's a good choice security wise.

I'm willing to work on this further. Please let me know what are your thoughts! @nlewo

(I realized just now that changing from build drvPath to outPath is not necessary, since memory hungry parts are show-derivation and nix eval. Please ignore changes to buildFunc in the commit.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants