Submitting results from non-pytest sources #

When the test isn't a pytest function — LabVIEW, TestStand, a custom script, a legacy framework — use the Python LitmusClient to push results into the same store the pytest plugin writes to. The same litmus runs, litmus serve, and DuckDB queries see them.

Canonical reference #

The full API surface — LitmusClient, RunBuilder, StepBuilder, VectorBuilder, every method signature, the LabVIEW / TestStand / CLI integration patterns — lives on the Python client reference. This page is the integration-level entry point; that page is the API.

When to use which path #

You haveUse
Python code with the results in handLitmusClient — chained builder, writes directly to the store
pytest testsThe pytest plugin, NOT this — see Litmus fixtures
Shell script or non-Python toolchainWrap the Python client in a one-file CLI; call it via subprocess
LabVIEWLabVIEW pattern in client.md — Python Node call
TestStandTestStand pattern in client.md — Python adapter

HTTP API caveat #

POST /api/runs does NOT accept submitted results. It launches a pytest subprocess against a test_path. For results submission from non-Python sources, the supported path is the Python LitmusClient (wrapped behind a thin CLI or subprocess if needed). An HTTP results-submission endpoint is not currently shipped — see the open follow-up.

Querying results #

Once results are in the store, query through any of:

  • client.list_runs() / client.get_run() / client.get_measurements() — see client.md
  • CLI: litmus runs, litmus show <run_id> — see cli.md
  • HTTP: GET /api/runs, GET /api/runs/{run_id}, GET /api/runs/{run_id}/measurements — see api.md
  • Raw parquet via DuckDB / pandas / Polars — see parquet-schema.md for columns and three-stores.md for the on-disk layout

See also #