[mgaunard]

The main problem is that builds require a variable amount of cores depending on what needs to be (re)built. The ideal thing to do is to have the build system itself orchestrate remote builds, since it actually knows how many things need building and how expensive they are.

[nixbuild]

This is what nixbuild.net does, it tracks historic CPU and memory usage of individual builds, and takes that into account when deciding what resources to allocate for new builds. You can configure limits on max/min CPUs on your account or individual builds. Also, if a build runs out of memory we simply restart it with more memory. The client will just see that the build log starts over.

[mgaunard]

That's precisely what I'm not describing; Nix doesn't even have access to the build DAG.

[nixbuild]

Please correct me if I'm wrong, but I assume you mean Nix doesn't have access to the build DAG that may exist inside the hermetic environment of individual Nix builds? If so, that's true, because Nix doesn't do that level of granularity unless you have a way to translate such DAGs into Nix derivations.

But Nix certainly tracks dependencies between Nix packages, and have knowledge about what packages need to be rebuilt if you make a change somewhere. Some of these packages might build config files, while other may build Chromium, ie wildly different CPU+mem needs.

[mgaunard]

Right, I'm arguing this is the wrong abstraction level, and that only the build system can make correct container sizing decisions.