feat(build.zig): cross-compile, install, and run on remote hosts over ssh

[dnut]

This makes it easy to use zig build to target a remote host while building, installing, and running executables.

Examples

Cross-compile all binaries for a remote host called myec2's build target and install them on that host:

zig build -Dssh-host=myec2

Compile, install, and run sig on myec2:

zig build -Dssh-host=myec2 sig -- gossip -n testnet

Run the tests on myec2:

zig build -Dssh-host=myec2 test

How it works

Determine the build target: ssh.getHostTarget - SSH into the server, run zig targets, then parse the json.

Install to the remote host: ssh.addSendArtifact - Analogous to Build.addInstallArtifact, except that it installs on a remote server. Uses Build.addSystemCommand to call rsync if installed, falling back to scp. rsync is preferred since it uses checksums to avoid redundant uploads. This depends on an InstallArtifact step.

Run on the remote host: ssh.addRemoteCommand - Analogous to Build.addSystemCommand, except that it runs on a remote host. Uses Build.addSystemCommand to run ssh.

CLI arguments

  -Dssh-host=[string]          Builds will target this remote host, binaries will be installed there, and executables will run there.
  -Dssh-installdir=[string]    When using ssh-host, this configures the directory to install binaries (relative to ssh-workdir) (default: zig-out/bin).
  -Dssh-workdir=[string]       When using ssh-host, this configures the working directory where executables will run (default: sig).

This is also compatible with no-run and no-bin. Those options will be respected when deciding whether to install or run the binary on the remote host, with one exception. If you specify only no-bin for an artifact that needs to run on the remote host, then it will still install the artifact, because that is necessary in order to run it.