[SPIKE] Release readiness dashboard — visualize blockers, bumps, and release actions

[mauromorales]

Context

Preparing a Kairos release today involves manually tracking state across many repositories, issues, PRs, dependency versions, and CI pipelines. Maintainers assemble this picture by opening multiple GitHub tabs, scanning Renovate PRs, checking the kairos-io/security repo, and working through a release issue checklist like #4095.

This is error-prone and time-consuming. We want a single place that answers:

Can we release now? If not, what specifically needs to happen?

This issue tracks designing (and ideally prototyping) an interactive release readiness dashboard for Kairos maintainers.

Related: #4122 (dependency upgrade strategy spike) — the dashboard should integrate with whatever upgrade workflow we land on there.

Goal

Build (or extend) a tool that gives maintainers an at-a-glance, interactive view of release readiness across the Kairos ecosystem, replacing much of the manual tab-hopping currently required when cutting a release.

Starting point: extend plugdash

@Itxaka's plugdash is a strong foundation. It already provides:

• A plugin-based dashboard server (Go binary + embedded web UI)
• GitHub plugins for releases, PRs, issues, CI status, milestones, stale items, review queue
• dependency-freshness — compares direct go.mod / package.json deps vs latest releases
• osv-vulns — known vulnerabilities for a package version
• file-version — reads pinned dependency values from files on a repo branch (e.g. kairos-init version in the Dockerfile)
• docker-image — checks whether expected image tags exist in a registry
• Config-as-code via YAML (--config), SSE live updates, and a hybrid UI + declarative tracker model

Evaluate extending plugdash (upstream contributions and/or Kairos-specific plugins/config) rather than building a separate tool from scratch.

What the dashboard should show

Release readiness summary

A top-level widget (or dedicated view) that gives a clear go / no-go signal for the current target release, e.g.:

• 🟢 Ready — all blockers resolved, checklist complete, CI green
• 🟡 Blocked — N items need attention (with links)
• 🔴 Not ready — critical blockers (CVEs, failing CI, open release-critical issues)

Dependency & version bumps

Surface what is out of date or mismatched across Kairos-related repos:

Component	Current (pinned)	Latest	Action needed
kairos-init	…	…	bump + release
osbuilder	…	…	up to date
k3s (×3 versions)	…	…	update
auroraboot	…	…	bump
…

Leverage existing plugdash plugins (dependency-freshness, file-version, github-releases, docker-image) and identify gaps.

Open tickets & PRs blocking release

• Issues/PRs tagged for the target milestone or release label
• Open Renovate/update PRs that need merging before release
• Critical/high-priority issues from kairos-io/security
• Docs repo open PRs that should land before release
• Stale release-related items needing a decision (close, defer, or fix)

CI & artifact health

• CI status across key repos (kairos, kairos-init, osbuilder, kairos-agent, …)
• Release artifact completeness for latest/pre-release tags (ISOs, checksums, multi-arch images)
• Workflow health trends (recent failure rate)

Release checklist (interactive)

Embed the release checklist from our release issue template — as used in #4095 — as an interactive checklist widget:

• Stage 0 - Finishing Touches
  • Check for critical CVEs in internal components
  • Verify binary versions in kairos-init Makefile
  • Bump and release kairos-init if needed
  • Bump kairos-init version in kairos Dockerfile
  • CI tests passing
  • Kairos docs PRs merged
  • osbuilder at desired version
  • k3s versions correct (latest 3 available)
  • Consider cutting rc/alpha
• Stage 1 - Manual testing (generic hardware + RPi scenarios)
• Stage 3 - Release (tag, update release notes, trigger docs CI)
• Stage 4 - Announcement (blog post)

Checklist state should persist (per release target / milestone) and contribute to the go/no-go signal.

Interactive actions

The dashboard should not just display state — it should let maintainers act from it:

• Request a dependency bump — trigger an upgrade PR (via Renovate dashboard checkbox, Updatecli, or whatever workflow #4122 recommends)
• Mark checklist items done — with optional link/comment
• Retry a failed CI run (if feasible via GitHub API)
• Open/create a release issue pre-populated from current dashboard state
• Snooze / defer a non-blocking item to a future release

Start with read-only visualization; define which actions are feasible in v1 vs. later.

Repositories & components to track

At minimum, the dashboard should cover:

• kairos-io/kairos
• kairos-io/kairos-init
• kairos-io/osbuilder
• kairos-io/kairos-agent
• kairos-io/kairos-docs
• kairos-io/security
• Key container images on quay.io (auroraboot, kairos images, …)
• k3s version pins

Document the full list during the spike.

Questions to answer

1. Extend plugdash vs. fork vs. separate tool — what's the right contribution model?
2. New plugins needed — what can't existing plugdash plugins do today? (e.g. cross-repo version matrix, release checklist persistence, go/no-go aggregation)
3. Data sources — GitHub API, Renovate Dependency Dashboard, OSV, quay.io, file pins across repos — what's the integration plan?
4. Release target model — how do we scope the dashboard to a specific version (e.g. v4.1.1)? Milestone? Release issue? Manual selector?
5. Hosting — run locally, shared maintainer instance, CI artifact, or deployed service?
6. Auth & permissions — read-only for most viewers; which actions need elevated tokens?
7. Relationship to release issues — does the dashboard replace, supplement, or sync with issues like #4095?

Deliverables

• Inventory of existing plugdash plugins vs. Kairos release needs (gap analysis)
• Wireframe or screenshot mockup of the release readiness view
• Working PoC (plugdash config and/or new plugins) demonstrating at least:
  • Go/no-go summary for a target release
  • Dependency/version bump matrix for key components
  • Embedded release checklist
• List of interactive actions feasible for v1
• Recommendation: upstream to plugdash vs. Kairos-specific layer
• Follow-up implementation issue(s)

Out of scope

• Automating the release itself (tagging, publishing assets) — this is about visibility and decision support
• Replacing the release issue template entirely (at least initially — the dashboard should complement it)

References

• Itxaka/plugdash — plugin dashboard server
• plugdash plugin catalog
• Release issue template
• Kairos release v4.1.1 (#4095) — example release issue with checklist
• #4122 — dependency upgrade strategy spike