Management wants a pass-rate trend on the wall screen. Today somebody screenshots the console output on Monday morning. I would like to do this properly but I cannot tell which of the four things SDODS produces I should build on: the dashboard/ directory, summary.json, the ingested database, or the REST API.
Roughly 40 runs a week across three projects, sharded four ways. The wall screen is a browser pointed at a URL and nothing else.
Depends how much you want to own.
The dashboard/ directory in a run is already a wall screen for one run: index.html is self-contained — totals, pass rate, the flaky list, heals, failure clusters and links into the step narratives — with the chart library inlined so it works offline and survives being mailed. metrics.json sits beside it when you want to script against the same numbers. What it is not is a trend; it only knows about itself.
For a trend you need the runs ingested, and at that point the web UI already has the page you are describing:
Point the wall screen at that first. If it turns out to be the wrong shape for your team, build on the same API it reads rather than on files.
The routes are the stats ones:
GET /api/stats/trends
GET /api/stats/flaky
GET /api/stats/heal
GET /api/stats/insights/api/stats/insights is the same computation sdods insights show prints — suite health and its trend, scenarios by flakiness, locators by fragility, environment stability — so the wall screen and the CLI cannot disagree.
Authenticate with a token from sdods tokens create. A read-only scope is enough, and please do not put an admin token in a page that is on permanent display in an office. Ingest is the prerequisite for all of it: sdods run --ingest, or sdods report ingest after the fact.
REST API has the scope table.
One decision to make up front, because it is annoying to change later: what a "run" means to the wall screen when you shard four ways.
Shards merge into one run on ingest, so the database gives you a single row with merged totals — which is what a pass rate wants. summary.json on a shard is that shard only, and four shards produce four files that each look like a complete run.
If you build on files anyway you have to merge them yourself:
sdods report merge shard-1 shard-2 shard-3 shard-4 --run 0196a72c-3f18-7b55-9d20-c4a7e015b88fThat rebuilds one HTML report and one JUnit file from --reporter blob --shard i/n output. It works, but it is a lot of pipeline to maintain for a number the database already has.
Have a different question? Ask it.