Skip to main content
Six commands cover the day-to-day loop. They all accept the same labels and target patterns, and they all share three global flags:

​
rbs build

Builds one or more targets, resolving the full dependency closure, executing in dependency order, and running independent targets in parallel. Results come from the shared cache when nothing relevant changed.
Key flags:
Before executing, rbs prints the execution plan — every target in the closure and what it depends on — so you can see exactly what a build will do.

​
rbs test

Builds the requested targets and runs the ones that are tests. Test targets are the ones declared with a test rule (go_test, py_test, vitest_test, and so on — any rule whose kind ends in _test or is registered as a test).
Test output is captured under .rbs/testlogs/<platform>/<package>/<name>/test.log, so a noisy suite doesn’t scroll your terminal history away.
rbs test does not enforce coverage thresholds. If a test target declares min_line_coverage (or branch/function thresholds), rbs test runs it and prints a reminder — the gate only fires under rbs coverage.

​
rbs run

Builds a target (and its dependencies), then executes it.

​
Multiple targets in parallel

Pass several targets — or -p/--parallel — and rbs builds them all first, then runs them simultaneously. Ctrl+C stops every process. This is the standard way to bring up a local stack:

​
Watch mode

--watch rebuilds and restarts the process whenever source files change:

​
Side-effect targets

Building stays pure — nothing a build does touches the outside world. Rules whose whole point is a side effect (pushing an image, applying manifests) perform it at run time instead:

​
rbs query

Lists targets matching a pattern without building anything. Useful for exploring a workspace and for scripting.

​
rbs graph

Emits the unified dependency graph of the whole workspace — build targets, infra resources, CI workflows, and external dependencies — by evaluating every .rbs file and walking the result.
Progress messages while the workspace loads go to stderr, so stdout carries only the document and stays pipeable:

​
rbs coverage

Runs test targets with coverage collection and enforces the thresholds the targets declare. This is the coverage gate for CI.
A test rule declares its thresholds as attributes; the run fails if the measured coverage drops below them:
go_test supports min_line_coverage; the JavaScript test rules (vitest_test, nodejs_test) additionally support min_branch_coverage and min_function_coverage. A threshold of 0 (the default) means no gate. Coverage reports and logs land under .rbs/testlogs/<platform>/<package>/<name>/coverage/.
Make rbs coverage //... part of your CI workflow. Since rbs test deliberately does not enforce thresholds, teams typically run rbs test in the inner loop and rbs coverage as the merge gate.