Record builder host name in build provenance

[edolstra]

Motivation

This keeps track where a build was done.

Depends on #340.

Context

Summary by CodeRabbit

• New Features
  • Added hostname tracking to build provenance records, enabling visibility into which build host created each derivation.
  • Provenance display now includes build host information when showing derivation history.
  • New configuration setting to customize the hostname used in provenance tracking.

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR adds hostname tracking to build provenance by introducing a configurable hostName setting in Settings, implementing a hostname getter with caching, extending the BuildProvenance struct to include an optional buildHost field, and updating JSON serialization/deserialization and display logic to surface the build host information.

Changes

Cohort / File(s)	Summary
Settings Infrastructure src/libstore/globals.cc, src/libstore/include/nix/store/globals.hh	Added hostName setting and getHostName() accessor with POSIX hostname caching on non-Windows systems using gethostname().
BuildProvenance Structure src/libstore/include/nix/store/provenance.hh	Extended BuildProvenance struct with optional buildHost field and updated constructor signature to accept and initialize this parameter.
Provenance Serialization src/libstore/provenance.cc	Updated BuildProvenance::to_json() to include buildHost field and extended JSON deserialization to read and pass optional buildHost when reconstructing BuildProvenance.
Integration src/libstore/unix/build/derivation-builder.cc	Updated BuildProvenance construction call to pass settings.getHostName() as the new hostName parameter.
Display & Documentation src/nix/provenance.cc, src/nix/provenance-show.md	Modified provenance logging output to display build host information appended as " on " and updated example documentation to reflect the new format.
Tests tests/functional/common/init.sh, tests/functional/flakes/provenance.sh	Added host-name = test-host configuration to test nix.conf and extended provenance test cases to validate buildHost field presence in output.

Sequence Diagram

sequenceDiagram
    participant Settings
    participant DerivationBuilder as Derivation Builder
    participant BuildProvenance
    participant JSON as JSON Serialization
    participant Display as Provenance Display

    DerivationBuilder->>Settings: getHostName()
    Settings->>Settings: Check cached hostname
    alt Cached
        Settings-->>DerivationBuilder: Return cached hostname
    else Not cached
        Settings->>Settings: Call gethostname() via POSIX
        Settings-->>DerivationBuilder: Cache and return hostname
    end

    DerivationBuilder->>BuildProvenance: construct(drvPath, output, buildHost, next)
    BuildProvenance->>BuildProvenance: Initialize buildHost field
    BuildProvenance-->>DerivationBuilder: BuildProvenance created

    BuildProvenance->>JSON: to_json()
    JSON->>JSON: Serialize buildHost field
    JSON-->>BuildProvenance: JSON with buildHost

    JSON->>Display: Read buildHost from JSON
    Display->>Display: Format "on <buildHost>"
    Display-->>Display: Output provenance with host info

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• Add subcommand 'nix provenance show' #340: Modifies BuildProvenance construction, JSON serialization/deserialization, and provenance display logic—directly overlapping with this PR's changes to the same structures and workflows.

Suggested reviewers

• cole-h

Poem

🐰 A rabbit hops through code so neat,
Adding hosts to make provenance complete!
From Settings we cache the machine's true name,
Through BuildProvenance it flows, never tame—
In JSON it dwells, on display it gleams,
Build host recorded in all of our dreams! ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 8.33% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically describes the main change: recording the builder host name in build provenance, which directly aligns with the core functionality added across all modified files.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch record-build-host

---

No actionable comments were generated in the recent review. 🎉

Tip

Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

tests/functional/common/init.sh (1)

46-56: ⚠️ Potential issue | 🟠 Major

Set host-name for the NixOS test config too to keep provenance deterministic.

Line 55 adds a fixed host name for the non‑NixOS path, but the NixOS branch’s test_nix_conf does not set it. If tests run on NixOS, buildHost will vary by machine and can make provenance assertions flaky.

🔧 Suggested fix

@@
 cat > "$test_nix_conf" <<EOF
 # TODO: this is not needed for all tests and prevents stable commands from be tested in isolation
 experimental-features = ${experimental_features:-}
 flake-registry = $TEST_ROOT/registry.json
 show-trace = true
+host-name = test-host
 EOF

🤖 Fix all issues with AI agents

In `@src/libstore/globals.cc`:
- Around line 270-279: The getHostName implementation uses POSIX APIs
(gethostname and HOST_NAME_MAX) but lacks the required headers and platform
guards; update the file to include <unistd.h> and <limits.h> (or <climits>) when
not on Windows and wrap the POSIX-specific code with an `#ifndef` _WIN32 (or `#if`
defined(__unix__) || defined(__APPLE__)) guard so Windows builds skip or provide
an alternative, and ensure the Settings::getHostName() implementation references
gethostname and HOST_NAME_MAX only inside that guarded section.

[github-actions]

🚀 Deployed on https://698b88c49a49be71a2065efe--determinate-nix.netlify.app

[cole-h]

LGTM.

$ ./result/bin/nix provenance show .#nix-store-static --store /tmp/foostore  --extra-experimental-features provenance
/nix/store/kxdn5ql8wbq9kgdzinkcr48x32557xm8-determinate-nix-store-static-x86_64-unknown-linux-musl-3.15.2
← built from derivation /nix/store/d5nkhxqk3ppmxi3jr13a1ap82dly3wv5-determinate-nix-store-static-x86_64-unknown-linux-musl-3.15.2.drv (output out) on scadrial
← instantiated from flake output git+file:///home/vin/workspace/detsys/nix-src?rev=6cae017ca69d0b95b9e8a60ebc3f4ed0ce8b64b5#packages.x86_64-linux.nix-store-static

[cole-h]

I wonder if it would also be a good idea to include the native architecture, if that's easy to get...

[edolstra]

Related to that, we should probably record the system attribute of the derivation, so we can query what system a store path is for. Currently there is no way to get that info unless you have the deriver around.