Mic92 / nix-fast-build

nix-fast-build 🚀 Combine the power of with to speed-up your evaluation and building process. works with both flakes and plain Nix expressions, and can integrate with remote machines by uploading the current flake, performing the evaluation/build remotely, and then transferring the resultant store paths back to you. Why ? **Problem**: Evaluating and building big flakes i.e. with numerous NixOS machines can be painfully slow. For instance, rebuilding the already-compiled disko integration test suite demands 1:50 minutes on an AMD Ryzen 9 7950X3D. But, it only takes a 10 seconds with . **Solution**: makes builds faster by evaluating and building your nix packages concurrently, reducing the overall time. How Does It Work? Under the hood: • It leverages the output from to evaluate flake attributes in parallel. • As soon as attributes complete evaluation, initiates their build, even if the overall evaluation is ongoing. • Lastly, to show the build progress nicely. • (Optional) Once a build finishes, can initiate its upload to a designated remote binary cache. Usage To get started, run: or: This command will concurrently evaluate all systems in and build the attributes in . --- Enjoy faster and more efficient NixOS builds with ! Building non-flake Nix expressions also works with plain Nix expressions (no flake required) via the flag: If is passed without a file argument, it defaults to . Use to select a specific attribute, just like : You can pass arguments to the Nix expression with and , and extend the Nix search path with : Evaluation in mode is impure by default (allowing , , etc.). Use to enforce strict pure evaluation. **Note:** Remote building ( ) is not supported in mode, since there is no flake archive mechanism to upload arbitrary Nix expressions to a remote machine. Remote building When leveraging the remote-builder protocol, uploading pre-built paths or sources from the local machine can often turn into a bottleneck. does not use the remote-builder protocol. Instead it uploads only the flake and executes all evaluation/build operations on the remote end. At the end will download the finished builds to the local machine while not having to download all build dependencies in between. Here is how to use it: Replace with your SSH login credentials for the target machine. Please note that as of now, you must be recognized as a trusted user on the remote endpoint to access this feature. CI-Friendly Output By default, (abbreviated as ) updates its output every 0.5 seconds. In standard terminal environments, this frequent update is unnoticeable, as erases the previous output before displaying the new one. However, in Continuous Integration (CI) systems, each update appears as a separate line of output. To make output more concise for CI environments, use the flag. This replaces with a streamlined status reporter, which updates only when there's a change in the number of pending builds, uploads, or downloads. CI Job Summaries When running in GitHub Actions, Gitea Actions, or Forgejo Actions, nix-fast-build automatically generates job summaries that appear directly in the CI UI. The summary includes: • Overall build status with success/failure counts • Detailed sections for each failed build with build logs • Collapsible sections showing successful operations (builds, evaluations, uploads, etc.) This feature is automatically enabled when one of the following environment variables is available: • (GitHub Actions) • (Gitea Actions) • (Forgejo Actions) **Note:** Job summaries are fully supported in GitHub Actions. Gitea and Forgejo set the environment variables but do not yet display the summary content in the UI (see gitea#23721). The summary file is still written, so it will work once support is added upstream. Example workflow: Build logs for failed packages are retrieved using and displayed in collapsible sections within the summary. Very long logs are automatically truncated to the last 100 lines. Avoiding Redundant Package Downloads By default, will download pre-built packages, leading to needless downloads even when there are no changes to any package. This can be especially burdensome for CI environments without a persistent Nix store, such as GitHub Actions. To optimize this, use the flag with . This ensures that only those packages missing from the binary caches will be built. Specifying Build Systems By default, evaluates all architectures but only initiates builds for the current system. You can modify this behavior with the flag. For instance, using will prompt builds for both and architectures. Ensure that your system is capable of building for the specified architectures, either locally or through the remote builder protocol. Building different flake attributes by default builds , which refers to all checks for the current flake. You can modify this default behavior by using the flag to specify a different attribute path. Example: **Note:** Always provide the complete flake path. Unlike , does not iterate over different attributes; the full path must be explicitly stated. Only evaluate the current system By default nix-fast-build will evaluate all systems in , you can limit it to the current system by using this command: Cachix support nix-fast-build can upload to cachix like this: nix-fast-build assumes that your current machine is either logged in to cachix or has the environment variables or set. These environment variables are currently not propagated to ssh when using the flag, instead the user is expected that cachix credentials are configured on the remote machine. Attic support nix-fast-build can upload to attic like this: nix-fast-build assumes that your current machine is either logged in to attic. Authentication is not propagated to ssh when using the flag, instead the user is expected that attic credentials are configured on the remote machine. Niks3 support nix-fast-build can upload to a niks3 server like t…