WIP: feat: hermetic build for enola #1730 (dumb build)

[dotdoom]

Relates to #1730.

[gemini-code-assist]

Summary of Changes

Hello @dotdoom, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request focuses on enhancing the build process for the enola application by implementing a more hermetic approach within the flake.nix configuration. The changes involve explicitly defining and utilizing a local Bazel Central Registry for dependency resolution and incorporating an output hash to ensure the determinism of the build artifacts. This significantly improves the reproducibility and reliability of the enola build.

Highlights

• Bazel Central Registry Pinning: The bazel-central-registry is now explicitly fetched from GitHub and pinned to a specific commit, ensuring a controlled source for Bazel dependencies.
• Hermetic Bazel Build Configuration: The Bazel build command for enola_deploy.jar has been updated to use the locally pinned bazel-central-registry, making the build more isolated and reproducible.
• Nix Output Hashing: An outputHash has been added to the enola package derivation in flake.nix, which guarantees that the build output is deterministic and matches a known hash.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request makes the Nix build for enola hermetic by pinning the Bazel Central Registry and using a fixed-output hash for the derivation. This is a great step towards fully reproducible builds. My review includes a couple of suggestions to improve the maintainability and align the changes with Nix Flakes best practices. Specifically, I recommend declaring the Bazel registry as a flake input and adding a comment to explain the maintenance of the outputHash.

[gemini-code-assist]

While using fetchFromGitHub works, a more idiomatic approach with Nix Flakes is to declare this dependency as a flake input. This improves clarity by centralizing external dependencies in the inputs section and leverages the flake.lock file for pinning.

You could achieve this by:

1. Adding bazel-central-registry to your inputs in flake.nix:

   inputs = {
     # ... other inputs
     bazel-central-registry.url = "github:bazelbuild/bazel-central-registry/4fcc47180cfe24915dae5705074c3994c60dc6b7";
   };

2. Passing bazel-central-registry as an argument to the outputs function.
3. Removing this let binding and using the bazel-central-registry variable from the function arguments directly in your bazel build command.

This change would make your flake's dependency management more robust and easier to follow.

[gemini-code-assist]

Using a fixed outputHash is a correct way to ensure a reproducible build for a derivation that has network access (like Bazel fetching dependencies). However, it can be a maintenance hurdle, as any change affecting the output requires manually updating this hash.

To improve maintainability for future contributors, it would be very helpful to add a comment explaining why this hash is necessary and how to update it. This will save others time when they encounter a hash mismatch error.

            # This is a fixed-output derivation. Bazel's dependency fetching is considered
            # an impurity by Nix, so we lock the output hash to ensure reproducibility.
            # If you change dependencies or source code and the build fails with a hash
            # mismatch, update this value to the 'got' hash from the Nix error message.
            outputHash = "sha256-hHa+tqNDxe3+Tl190xPWiNiCq0HWU5qcc52rjo3Ncl0=";