.rbs files,
RBS-native CI, cluster jobs, SQL migrations, and remote build services. Global
flags are documented in the
CLI overview.
rbs infra
Manage infrastructure defined purely in the build language using theinfra.*
SDK: plan and apply changes, inspect state, and browse provider schemas.
Within
rbs infra, -e/--env selects the infra workspace — it is not the
build environment selector that -e means on every other command.rbs infra plan
Generate a plan showing what infrastructure changes will be made: resources created, updated, deleted, or unchanged. No actual changes are made.rbs infra apply
Apply the infrastructure changes described in the plan — creating, updating, or deleting resources as needed to match the desired state defined in your.rbs files.
rbs infra destroy
Destroy all infrastructure resources in the current workspace. This deletes all managed resources — use with caution.rbs infra show
Display the current infrastructure state: all resources tracked in state along with their attributes and dependencies.rbs infra output
Display output values from the infrastructure. Without arguments, shows all outputs; with a name argument, only that output.rbs infra env
Resolve the environment a service gets from the infra it uses. Each infra resource type declares conventional env exports (a database exportsDATABASE_HOST/DATABASE_PORT, a bucket exports STORAGE_BUCKET, …);
values are resolved from the applied state.
rbs infra graph
Display the declared infrastructure resources and their dependency edges.rbs infra refresh
Update the state file to match the actual infrastructure. Reads the current state from cloud providers and updates the local state without making any changes.rbs infra import
Import an existing resource into RBS state management, bringing existing infrastructure under RBS management without recreating it.rbs infra verify
Smoke-test declared infra against the real providers — no credentials, no cloud calls. Every declared resource is expanded through its adapters and each emitted concrete resource is validated against the pinned provider binaries: schema validation plus a plan-time dry run. Catches wrong attributes, invalid values, and missing requirements before anything reaches apply. Server-side rules (quota, IAM, uniqueness) still need a real apply.rbs infra schema
Fetch a provider’s complete schema (every resource type it supports) and browse it. With a resource type argument, show that resource’s full attribute schema: types, required/optional/computed, sensitivity.rbs infra generate
Generate typed, validated.rbs resource definitions from a provider schema
into infra/<provider>/, grouped one file per service (aws_s3_* → s3.rbs).
Generated files use only public SDK builtins and are user-owned: edit them
freely or regenerate.
rbs infra scaffold
Scaffold a cross-cloud abstraction from provider schemas: an abstract resource type plus one adapter per provider mapping.rbs ci
Run RBS-native CI workflows with DAG execution — an alternative to GitHub Actions that uses RBS’s DAG executor for parallel job execution, with support for distributed workers.rbs ci run
Run one or more CI workflows declared inWORKSPACE.rbs or any ci.rbs file.
If no workflow name is given, all workflows matching the trigger event run.
rbs ci plan
Resolve a trigger event into the job DAG it would run, printed as JSON on stdout. Nothing is executed and nothing is written. Matrix jobs are expanded andneeds is rewritten to name expanded jobs, so the DAG in the output is
the one that would actually be scheduled; if expressions are passed through
unevaluated. This is the seam an external scheduler uses — it can read a plan
without hosting an interpreter for the build language.
rbs ci list
List all CI workflows defined in the workspace.rbs ci affected
Detect and display packages affected by git changes — used by CI workflows to run only on changed packages.rbs ci status
Show the status of CI workflow runs.rbs ci trigger
Display the current CI trigger context based on git state.rbs job
Submit and manage cluster jobs (scheduler mode). Every subcommand talks to the cluster named by--server, defaulting to $RBS_REMOTE.
rbs job submit
Submit a job to the cluster.rbs job list
List jobs — active by default;--history includes finished jobs.
rbs job show
Show one job in full detail.rbs job logs
Print a job’s output.rbs job outputs
Download the files a job declared with--outputs. The worker collects those
paths into the cluster’s content store when the job ends — including when it
fails, so a crashed run’s checkpoints and logs are still recoverable. Files
are written under --dest with the layout the job wrote them in.
rbs job wait
Block until jobs finish; exits non-zero if any failed.rbs job cancel
Cancel jobs.rbs job queues
List queues, their limits, and occupancy.rbs job reserve
Create or cancel a maintenance window: new work stops and running work drains.rbs migrate
Manage SQL database migrations, Flyway-style: versioned and repeatable migration files with a history table per target database.rbs migrate create
Create a new versioned or repeatable migration SQL file.rbs migrate info
Show migration status for a target: which migrations are applied, pending, failed, and so on.rbs migrate validate
Validate that all applied migrations match their files on disk; exits non-zero if any issues are found. Use in CI to catch files modified after being applied (checksum mismatch), files deleted after being applied, and previously failed migrations that need attention.rbs migrate apply
Apply all pending versioned and outdated repeatable migrations in order. Each migration runs in its own transaction; on failure, the migration is recorded as failed and execution stops. A migration whose leading comments contain-- rbs:no-transaction runs its statements individually outside any
transaction (for statements like CREATE INDEX CONCURRENTLY). Concurrent
applies are safe: a database-side lock serializes migrators.