feat(api): wire per-tab lab filters and metrics lab health (#2059) - #2107
alanpeixinho wants to merge 2 commits into
Conversation
…2059) * filter_test.lab, filter_boot.lab, and filter_build.lab handlers with per-tab filter_labs * Lab filtering on tree, hardware, rollup, and commits history listings * Hardware POST filter body support for lab per boot/test/build tab * lab_maps builds/boots/tests as StatusCount on /api/metrics/ * covered_builds int on LabMetricsData * Faster covered-builds SQL via nested GROUP BY lab, build_id * Metrics email template, Metrics page, and frontend filter types updates * Unit tests for filters, metrics queries, notifications, and rollup Signed-off-by: Alan Peixinho <alan.peixinho@profusion.mobi>
f50d781 to
79d1c8c
Compare
| CASE | ||
| WHEN t.path = 'boot' OR t.path LIKE 'boot.%%' THEN 'boot' | ||
| ELSE 'test' |
There was a problem hiding this comment.
This CASE puts every non-boot path in test, including NULL, so lab test totals can jump vs the previous email with no real volume change. Unless I'm missing something
| assert params["end_date"] == "2026-06-14T00:00:00+00:00" | ||
|
|
||
|
|
||
| class TestLabMapsFromStatusRows: |
There was a problem hiding this comment.
This only tests lab_maps_from_status_rows with hand-built tuples.
The API change is that lab_maps entries are now StatusCount objects plus covered_builds. I don't see in our CI any checks that GET /api/metrics/ actually returns that shape, so we could ship ints again and not notice.
Can we assert that on a response (here or in the metrics integration test)?
There was a problem hiding this comment.
I believe Pydantic should catch schema changes, but I still like the idea of introducing some integration as well.
What it is
Closes #2059. Per-tab lab filters for tree and hardware APIs (
filter_test.lab,filter_boot.lab,filter_build.lab), including hardware POSTfilterbodies./api/metrics/lab_mapsnow exposes per-labStatusCountfor builds, boots, and tests, pluscovered_buildsfor the email “Covered builds” column. Covered-builds SQL uses nestedGROUP BY lab, build_id.What to test
boots/tests/builds:filter_boot.lab,filter_test.lab,filter_build.lab(query + POST where supported); builds filter on build lab, not test labboots/tests/builds/summary: POSTfilterwith per-tab lab keys; lab + status togetherGET /api/metrics/: response includes newcovered_buildson each lab entry, andbuilds/boots/testsasStatusCountobjects (not plain ints)metrics_summaryemail: “Covered builds” totals and per-lab values match pre-change behaviour; boots/tests columns unchangedtest.labandboot.labstill work; builds tab not lab-filtered via UI (by design)Made with Cursor