Skip to content

Conversation

@Ericson2314
Copy link
Member

Motivation

More JSON!

CC @mschwaig @edef1c it occurs to me that perhaps BuildResult was (at least closer to) the type for build trace values we wanted all along. E.g. being able to sign build failures is cool, and if we move the signature here, we also sign for all the outputs at once as @mschwaig wanted.

Context

Depends on #14425


Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

Ericson2314 and others added 4 commits October 30, 2025 12:31
Progress on NixOS#13405, which asks for an explicit characterisation of the
equivalence relation like the one given here.

Also progress on NixOS#11895, because we're using the term "build trace
entry" instead of "realisation".

Mention NixOS#9259, a future work item.

Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Note, starting to make progress on NixOS#11895 by calling it this in the
manual.
@edolstra
Copy link
Member

FWIW Determinate Nix also has a JSON serialization for BuildResult: https://github.com/DeterminateSystems/nix-src/blob/236ebef6514f3a2a9765c8a1d80dd503b8e672be/src/libstore/build-result.cc. This is used to provide structured JSON log messages containing the build result. Might be worth having a look at that to avoid a compatibility issue.

One difference is that the status strings follow the enum values, i.e. ResolvesToAlreadyValid instead of resolves to already valid. I feel the use of whitespace falsely suggests that these are arbitrary human-readable strings rather than enum values.

@Ericson2314
Copy link
Member Author

That looks like the only difference? I'm happy to go back to camel case. I had a similar feeling after I did it that way too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants