Hummingbird Dashboard

Web dashboard and CLI for monitoring Konflux build pipeline status.

Features

• Web Dashboard - Real-time view of build, test, and release status
• Commits View - Detailed pipeline status per commit with expandable releases
• Components View - Latest status per component grouped by state
• Merge Requests View - Track build status across MR versions
• CLI Tool - Command-line access to pipeline data in YAML/JSON/table formats
• Failed Releases - View and manage failed releases with LLM-powered analysis
• Auto-Rerun - Automatically retry transient release failures
• Blocked Snapshots - Block/unblock snapshots from auto-rerun with error pattern matching
• Smart Triggering - Application-aware rules for determining affected components

Prerequisites

• Python 3.11+
• PostgreSQL database (via hummingbird-status or port-forward)

Installation

cd hummingbird-dashboard
pip install -e .

Usage

Local Development

cd hummingbird-dashboard

# Option 1: Port-forward to production database
./dev.sh port-forward  # In terminal 1
DATABASE_URL=postgresql://postgres@localhost:15432/events ./dev.sh start  # In terminal 2

# Option 2: Use local database (via hummingbird-status)
cd ../hummingbird-status && ./dev.sh db-start && ./dev.sh db-init
cd ../hummingbird-dashboard
DATABASE_URL=postgresql://postgres:dev@localhost:5432/events ./dev.sh start

The dashboard runs at http://localhost:8080 with live reload.

Web UI

CLI

# View latest commit status
hummingbird-dashboard --application myapp --format table commit

# View specific commit
hummingbird-dashboard --application myapp commit abc1234

# View multiple commits
hummingbird-dashboard --application myapp --format table commit --limit 10

# Component status overview
hummingbird-dashboard --application myapp component

# JSON output
hummingbird-dashboard --format json commit | jq .

# Auto-rerun failed releases
hummingbird-dashboard auto-rerun

# Analyze failed releases via LLM
hummingbird-dashboard analyze-failures

Configuration

Environment Variables

Authentication Variables

These control the retrigger functionality (requires OAuth proxy in production):

For local development with retrigger enabled:

TRIGGER_AUTH_MODE=local DATABASE_URL=... ./dev.sh start

Auto-Rerun Variables

These control the auto-rerun cronjob and failure analysis:

Failed Releases

The /releases/failed page shows all failed releases with:

• LLM Analysis — Each failure is analyzed by Gemini with root cause, classification, and recommendation
• Failure Classification — Transient, Configuration, Code, External Service, or Unknown
• Rerun History — Past rerun attempts and outcomes per snapshot
• Error Pattern Matching — Auto-block snapshots matching known error patterns
• Auto-Rerun — Automatically retry transient failures (configurable via dashboard toggle)
• Analysis Toggle — Enable/disable LLM analysis from the dashboard

CLI Subcommands

The auto-rerun subcommand retries eligible failed releases:

hummingbird-dashboard auto-rerun --application myapp

The analyze-failures subcommand runs LLM analysis on unanalyzed failures:

hummingbird-dashboard analyze-failures --managed-namespace rhtap-releng-tenant

Both are designed to run as Kubernetes CronJobs.

Merge Requests

The /mrs page shows merge requests across all monitored repositories with:

• State filter - Open, merged, closed, or all MRs
• Project filter - Filter by specific repository
• Build status - Aggregate status across all components

The /mr/{project}/{iid} detail page shows:

• All MR versions - Each head commit SHA that was pushed to the MR
• Build status per version - Full pipeline status (build, snapshot, test, release)
• Links to Konflux UI - Direct links to PipelineRuns and Snapshots

Versions are ordered by latest event timestamp, so force-pushed commits appear in the correct position even if they reuse an earlier SHA.

Component Status

The dashboard tracks component build status with these states:

Components are grouped by status: Failed/Stale → Running → OK → Missing.

Trigger Rules

The dashboard uses application-specific rules to determine which components are affected by a push:

• containers: Changes in images/{component} trigger builds
• rpms: Changes in rpms/{component} or mock/mock.cfg trigger builds
• tools: Changes in {component} directory trigger builds

Certain files are excluded from triggering (README, templates, etc.).

Development

See the main README for development workflows.

Running Tests

cd hummingbird-dashboard
pip install -e ".[dev]"
pytest

Project Structure

hummingbird-dashboard/
├── Containerfile
├── dev.sh
├── hummingbird_dashboard/
│   ├── analysis.py     # LLM failure analysis (Gemini)
│   ├── cli.py          # CLI entry point
│   ├── db.py           # Database connection
│   ├── konflux.py      # Konflux API client
│   ├── models.py       # Data models (Component, PushEvent)
│   ├── sources.py      # PostgreSQL queries
│   ├── table.py        # CLI table formatting
│   ├── triggers.py     # Application-specific trigger rules
│   ├── views.py        # Status computation and aggregation
│   └── web/
│       ├── app.py      # FastAPI application
│       └── templates/  # Jinja2 templates
└── tests/

Building Container Image

cd hummingbird-dashboard
podman build -f Containerfile -t hummingbird-dashboard .

License

This project is licensed under the GNU General Public License v3.0 or later - see the LICENSE file for details.