Test Runs Dashboard view

[vbelchio]

Summary

Add a dedicated Test Runs Dashboard view to Ibutsu for browsing recent runs, filtering them, expanding pass/fail/error/skip counts into individual tests, and reading those tests' logs — without leaving Ibutsu.

A standalone prototype already exists (ibutsu-test-runs-dashboard). It currently talks to Ibutsu over the public REST API through a separate backend proxy. For the in-tree version, data should come from ibutsu-server's existing connectors (SQLAlchemy models / db.session / apply_filters, the same path widgets and controllers already use) rather than an HTTP client against /run, /result, /artifact, or /project.

Motivation

The current Test runs page (frontend/src/pages/run-list.js) lists runs, but day-to-day triage often needs more:

• Filter by project, component, environment, source, and Jenkins job with regex (and optional min-failures / extra Ibutsu filter expressions)
• Expand a summary badge (e.g. 3 failed) to the matching results for that run
• Open a test and read its logs/artifacts in a side panel
• Save named filter views (bookmarks) and land on a Home page that shows the latest matching run for each bookmarked view
• Share a view via URL query parameters

That workflow is what the prototype implements as an external app. Folding it into Ibutsu avoids a second service, a second login/token, and a round-trip through the HTTP API for data Ibutsu already has in Postgres.

Proposed behavior

• New view (left nav and/or dashboard widget), similar in shape to Jenkins Job View / Compare Runs rather than a small chart widget
• Run table with pass / fail / error / skip (and related) summaries
• Clicking a result count expands the matching tests for that run
• Clicking a test opens logs/artifacts in a side panel
• Filters: project, component, env, source, Jenkins job (regex), minimum failures, and free-form Ibutsu {field}{operator}{value} expressions
• Filters reflected in the URL so views can be shared and bookmarked in the browser
• Named saved views, with an option to include each view's latest run on a Home aggregate
• Respect existing project membership / auth; do not expose a separate token to the browser

Architecture: use connectors, not the REST API

The prototype's backend is an HTTP proxy (IbutsuClient → /project, /run, /result, /artifact). That is the wrong fit inside ibutsu-server.

The in-tree implementation should query through the same backend connectors widgets already use, for example:

• ibutsu_server.db / db.session
• models such as Run, Result, Artifact, Project
• ibutsu_server.filters.apply_filters / convert_filter
• helpers already used by widgets (create_summary_columns, project scoping, etc.)

Suggested layout (same pattern as #137 and existing views):

1. Backend query module under backend/ibutsu_server/widgets/ (or a dedicated controller if a full view is cleaner than a widget)
2. Register the type in constants.py and WIDGET_METHODS (if it is a widget/view)
3. Frontend view under frontend/src/views/ (and VIEW_MAP in frontend/src/pages/View.js), using PatternFly like the rest of the UI
4. Saved views stored in Ibutsu (user- or project-scoped), not a sidecar JSON file

Do not add a second FastAPI/proxy process or call Ibutsu's own HTTP API from the backend.

Related

• Existing runs table: frontend/src/pages/run-list.js — keep it; this is a richer triage view, not a drop-in replacement unless that turns out to be simpler
• #137 Generic table view or widget
• #385 Per-user dashboards (saved views / Home)
• #457 Job Status Matrix Widget

Reference prototype

Internal prototype: https://gitlab.cee.redhat.com/vbelchio/ibutsu-test-runs-dashboard

Useful as UX and filter-behavior reference only. Persistence (JSON file), HTTP client, and disk cache should be rethought against Ibutsu's DB, auth, and any existing cache.