[alanpeixinho]

Summary

A lab row in the listing now opens a details page for that lab, using the same origin and time window. The page shows submission fill, distribution, and per-tree builds, boots, and tests.

Mock data only, from labDetailsMock.ts. Part of #2168.

Made with Cursor

[alanpeixinho]

Full page of the mock lab details.

[alanpeixinho]

left a small mockup, so we can iterate on the design of the proposed lab details page, any feedback would be appreciated.
cc: @tales-aparecida @bhcopeland @minash-ti

[nuclearcat]

IMHO data need to be sorted by priority. What people check daily and most often - current builds status, so it must be on top, and first page without scrolling must be that people come for - daily.
Then, submission fill and distribution - probably at bottom. But this is IMHO and i think important to have other opinions.

[alanpeixinho]

IMHO data need to be sorted by priority. What people check daily and most often - current builds status, so it must be on top, and first page without scrolling must be that people come for - daily. Then, submission fill and distribution - probably at bottom. But this is IMHO and i think important to have other opinions.

@nuclearcat To be fair, I was struggling with defining what is more important here. But I think I am with you here, those two aggregated are probably better going to the bottom. I will change and update the screenshot.

[alanpeixinho]

@nuclearcat Done. Build status is at the top. Distribution follows, and submission fill is last.

[felipebergamin]

I wonder if we could make the page more actionable by highlighting recent failures or items that need attention. The tree table provides a useful overview, but users still need to scan individual status counts to identify problems. A small summary of recent failures could help users quickly understand what needs investigation.

e.g. highlight trees with recent failures, platforms with recurring errors or tests that started failing.

I am not sure but maybe providing this kind of information would help the users to identify problems faster.

[alanpeixinho]

@felipebergamin I like the idea of a short list of what needs attention. Highlighting every tree or board that has some failures would cover most of the page, since a few failures are normal.

We looked at the lab data. A failure that shows up in one lab and not in another is easier to act on. The list could be:

• A board that does not boot in this lab, while the same tree, branch, and commit boots on that board in another lab.
• A test that fails in this lab and passes in another, on the same platform and build config.

Cases we found:

• On 5 October 2026, cd8180-orion-o6 failed to boot next/pending-fixes commit dcb935319e0e in pull-labs-demo, and booted that commit in lava-broonie.
• On 20 and 21 October 2026, kselftest on bcm2711-rpi-4-b with defconfig+lab-setup+kselftest for mainline/master failed 14 times in lava-broonie and did not fail in lava-collabora (495 passes).

Would it be more helpful to show what fails in one lab but not in the others?

[alanpeixinho]

@felipebergamin Do you think something like this could help? Did you have something different in mind?

[felipebergamin]

@felipebergamin Do you think something like this could help? Did you have something different in mind?

Yes, something like that.

[alanpeixinho]

Closing this draft. The lab details page landed in #2200.

[felipebergamin]

Closing this draft. The lab details page landed in #2200.

@alanpeixinho I believe your agent hallucinated. PR 2200 only ships the endpoints

[alanpeixinho]

@felipebergamin Right. #2200 only added the endpoints. This draft stays open as the mock for #2168. Connecting it to those endpoints is #2226.