The command line
zut’s CLI is a small set of commands dispatched from a single table, so zut help is always in sync with what the binary actually does.
$ zut help
Commands
zut build <label> [options]
Evaluate the BUILD file, analyze the target’s transitive graph, run the
resulting actions through the cache, and materialize the target’s declared
outputs into ./zut-out/.
$ zut build //:hello
$ zut build //crates:serde --jobs=4
zut test <label> [options]
Build <label>, then run its (test) binary as a cached action. An unchanged,
previously-passing test is a cache hit — it is not re-run. Accepts the same
options as build.
$ zut test //:mylib_test
//:mylib_test: PASS (cached)
test result: ok. 12 passed; 0 failed
zut fetch [Cargo.lock] [--jobs=N]
Download, checksum-verify, and unpack crates.io dependencies into the CAS, write
.zut/crates.lock, and generate //crates/BUILD. This is the only networked
command. See Fetching crates.io dependencies.
Options
These apply to build and test (and fetch honors --jobs):
| Option | Meaning | Default |
|---|---|---|
--sandbox=prep|namespace|landlock | Hermeticity tier | strongest available |
--jobs=N | Parallel actions | CPU count |
--profile | Per-action wall/cpu/peak-rss table | off |
--remote-cache=<spec> | Back the caches with a shared store | none |
--remote-cache-mode=read|read-write | Remote cache access | read-write |
--log-level=error|warn|info|debug|trace | Diagnostics verbosity | info |
--verbose | Shorthand for --log-level=debug | — |
--quiet | Shorthand for --log-level=off | — |
Every option can also be set in a .zutrc file using the
same name, so the command line stays short.
Labels
A label names a target:
//:name— targetnamein the workspace-rootBUILD.//path/to/pkg:name— targetnameinpath/to/pkg/BUILD.//crates:serde— a generated crates.io target.
Exit status
zut exits non-zero on any failure (missing target, evaluation error, action
failure, test failure). Errors are printed to stderr; machine-readable output is
reserved for stdout.