`demo-test` is an end-to-end test harness. It provisions demo data via the control plane /provision-demo API, runs setup + queries + cleanup SQL phases, and emits a JSON report.
delta-forge-cli demo-test <NODE> <ZONE> <DEMO_PATH> [TARGET_DIR] [flags]## Overview `demo-test` is the end-to-end demo harness used by CI and by the `demo-run` skill. Given a compute node, a target zone, and a repo-relative demo path, it calls the control plane `/provision-demo` API to download the demo's data and SQL files into `TARGET_DIR`, then executes the demo's three lifecycle phases (setup, queries, cleanup) in order against the selected compute node. A structured JSON report goes to stdout; human-readable progress goes to stderr. Because provisioning, variable injection, SQL execution, and reporting are all owned by this single command, a green `demo-test` run is a meaningful regression signal: it exercises authentication, the control plane's demo catalog, the compute node's engine, and zone storage in one pass. ## Behavior - The command runs five internal stages in order: authenticate, resolve compute node, compute health check, provision demo, then setup -> queries -> cleanup (filtered by `--phase`). - Provisioning always runs, even when `--phase` is `queries` or `cleanup`. This is what populates `{{data_path}}` and the demo's SQL files, and what decides which on-disk location the subsequent phases target. - `--local <DIR>` overrides only the SQL file paths. The provisioned data path still comes from the control plane, so you can edit `setup.sql`, `queries.sql`, or `cleanup.sql` locally and re-run without reprovisioning. - Before any phase executes, three variables are injected into each SQL file: `{{zone_name}}`, `{{data_path}}`, and `{{current_user}}`. See `CLI_DEMO_VARS`. - Exit code is 0 when every selected phase succeeds. Exit code 1 is returned when setup has any error or when queries has any failure or error. Cleanup errors are logged but do not fail the run. Exit code 2 is reserved for client-initialisation failures before any phase runs. - Output is split: the JSON report is printed to stdout (and is the only thing on stdout), while all progress, tables, and diagnostic messages go to stderr, making `>report.json` safe for capture. ## Compatibility - The command is available in every build of `delta-forge-cli`; it is not gated behind a feature flag. - The same harness is invoked programmatically by the `demo-run` skill and by regression jobs that compare report fields (`passed`, `failed`, `errors`, `total_execution_time_ms`) across releases. - For plain SQL scripts that do not have a demo manifest, use `run` instead. `run` does not provision, does not inject the demo variables, and does not understand phases.
delta-forge-cli demo-test prod-node-01 landing demos/csv/sales-quickstart# Iterate on queries only against a local SQL directory
delta-forge-cli demo-test prod-node-01 landing demos/csv/sales-quickstart --phase queries --local ./demos/csv/sales-quickstart# Full teardown
delta-forge-cli demo-test prod-node-01 landing demos/csv/sales-quickstart --phase cleanup --drop-schema --drop-zone# Capture the report for regression diffing
delta-forge-cli demo-test prod-node-01 landing demos/csv/sales-quickstart >report.json