Help with Nix Build and Incredibuild Integration - Network Restrictions Due to Sandboxing

I am currently working on a project that involves building a large C++ codebase (around 7,000 files) using Nix. To speed up the build process(from 2 hours down to 10 mins), the project was already using Incredibuild, a tool that allows for distributed compilation across multiple hosts and cores. However, I’ve run into a problem related to Nix’s sandboxing features.
Incredibuild runs processes on remote machines in a secure sandbox. Everything each process requires to run properly is dynamically emulated by Incredibuild from the local host to the remote machine. Any output generated by the process – std output, errors, return codes, files generated, etc. – is automatically synched back to the local host, as if the process had been executed locally.

The Issue:

Nix’s build sandboxing disallows network access by default. Unfortunately, Incredibuild requires network access to distribute the build tasks to other machines. Disabling sandboxing entirely is not an ideal solution for me, as it introduces several issues with the local environment interfering with the builds. This interference affects reproducibility and causes other unpredictable behavior.

What I’ve Tried:

  1. Nix Build Flags: I’ve experimented with various Nix build flags, but couldn’t find a configuration that allows network access for Incredibuild while keeping other sandboxing features intact.

What I’m Looking For:

Partial Sandboxing: Is there a way to selectively allow network access in the Nix build environment while retaining the other benefits of sandboxing?

Incredibuild Integration Tips: Has anyone successfully integrated Incredibuild with a Nix build system? If so, any guidance on managing the network restrictions without completely disabling sandboxing would be greatly appreciated. My last resort would be to patch nix sources for this.

The main exception to network sandboxing is FODs - so you can split the build into FOD(s) to download whatever’s needed and then use that downloaded result in the fully-sandboxed build.

That’s essentially what src does in most packages.

Thanks for your reply. Don’t believe this would work for me though as I need the network access during the build phase, essentially I pass the compilation command (e.g ninja -j 160) to incredibuild and they distribute it to hundreds of available cores in multiple hosts.
I am currently in the process of trying to use this:extra-sandbox-paths = /etc/nsswitch.conf=/etc/nsswitch.conf /etc/resolv.conf=/etc/resolv.conf /etc/hosts=/etc/hosts (plus whatever else is needed)

Yeah, that’s not really a thing within nix. You probably are looking for a general-purpose language at that point, or you’d have to fork nix to make remote builds not suck.

Yes, it doesn’t seem compatible with nix at all. Another approach I am thinking is to move the ~400 targets to separate nix packages and go with nix remote builds and caching(so no incredibuild). One problem I see is that there are some common headers that cause rebuild of 1500 files (lots of them from unit tests) and this would need a powerful box to build with a descent latency.