Skip to content

✨ Add Self-Hosted Runners View #19

@homeles

Description

@homeles

Summary

Add a dedicated tab/view in the RunWatch UI for monitoring self-hosted GitHub Actions runners. Currently, RunWatch focuses on workflow runs — this feature extends visibility to the runner infrastructure itself.

Motivation

Teams using self-hosted runners (bare metal, VMs, or ARC/Kubernetes) lack a centralized dashboard to see runner status, capacity, and utilization. This view would help ops teams quickly identify:

  • Which runners are idle vs busy
  • What job a busy runner is executing
  • ARC Scale Set capacity and queue depth

Acceptance Criteria

Core Requirements

  • New top-level tab/view in the sidebar (alongside Dashboard, Workflows, etc.)
  • Display all self-hosted runners with: name, status (idle/online/busy/offline), OS, labels, runner group
  • Show a direct link to the active job when a runner is busy
  • Support grouping by:
    • Scope level: Enterprise → Organization → Repository
    • Runner group
    • Labels

Filtering & Search

  • Filter by runner group, labels, runner name, status
  • Search bar with typeahead support
  • Persist filter selections in URL params

ARC / Kubernetes Integration (if feasible)

  • Display ARC Scale Set details: min/max replicas, current pod count, queued jobs
  • Investigate GitHub API support for Scale Set metadata (spike may be needed)

UI/UX

  • Use consistent Material UI components matching existing views
  • Real-time status updates via existing WebSocket infrastructure
  • Responsive layout for desktop and tablet

Technical Notes

  • GitHub API: Use the Self-hosted runners API — requires admin:org or repo scope
  • Backend: New endpoints in server/src/routes/api.js + new controller/service for runners
  • Frontend: New feature folder client/src/features/runners/
  • WebSocket: Extend Socket.IO events to broadcast runner status changes

Open Questions

  • Does the GitHub API expose ARC Scale Set metadata? (Needs spike/investigation)
  • Should runner data be polled on an interval or event-driven via webhooks?
  • What refresh interval is acceptable for runner status?

Size Estimate

🐘 L (1-3 days)

Metadata

Metadata

Assignees

No one assigned

    Labels

    backendServer/API changesfeatureNew feature or enhancementfrontendUI/client changes

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions