https://github.com/NixOS/nix/blob/master/src/libstore/remote-store.cc https://github.com/bazelbuild/remote-apis/blob/main/build/bazel/remote/execution/v2/remote_execution.proto
- works by ssh
- ssh in and call a binary
- communicates by stdin / stdout
- we write that binary
- nix-remote-build --custom-command
- not actual flag
- custom serialization
- everything padded to n*64 bits
- i64 (little-endian)
- String (len: u64, data, padding)
- wop*
- ops for messages server -> client
- some obsolete
- correspond to functions on the client
- lots of things depend on the version of the protocol
- (at first) ignore this and implement latest version
-
capture commands & don't do much
-
need to send something back
-
forward to regular binary?
-
another implementation of the same protocol is useful on its own
-
enum for operations
-
wire protocol
-
on EnsurePath we could do substitution (using the blob cache). Why do we sometimes get AddToStore and sometimes EnsurePath?
-
build an adaptation from nix store <-> bazel ca store it seems like nix calls AddToStore in dependency order, giving us the content each time, so we can compute the ca hashes
-
encode a nix store path as an action in the action cache (action cache maps from the input hash of a build action to its output hashes)
-
nix store queries can be turned into bazel actions
-
using nix as a remote builder seems much easier. From a clean nix store, the ops go:
- QueryValidPaths for the paths we want. Returns empty (when builders_use_substitutes is true, the builder does the downloading and returns the full set of paths)
- AddMultipleToStore for adding everything
- BuildDerivation build everything
- QueryPathInfo