Objective
Teach Launchplane to inventory and reason about self-hosted GitHub Actions runner lanes across managed repos.
Finish Line
Launchplane can report runner lanes and capacity signals without mutating runners
Current Status
State: Future work; not needed before the sequential merge train MVP, but useful before Launchplane starts making scheduling decisions across repos.
Next action: Design a runner-lane inventory record and a read-only discovery command/API.
Blocked by: None.
Last verified: 2026-05-07 after adding a third SYO runner lane manually on chris-testing.
Scope
- Read-only discovery of GitHub self-hosted runners for selected repos.
- Host/lane naming conventions, labels, busy/idle status, and runner health.
- Queue-wait metrics from recent workflow runs where GitHub exposes enough timing.
- Operator UI/API summary of runner capacity by repo and host.
- No automatic provisioning, draining, scaling, or deletion in this phase.
Acceptance Criteria
- Launchplane can discover runner lanes for a repo and persist or present a normalized inventory.
- Inventory captures runner name, GitHub id, status, busy flag, labels, repo, host hint, and last observed timestamp.
- Launchplane can report lane count for cbusillo/sellyouroutboard and detect the three chris-testing SYO lanes.
- Recent workflow run inspection can separate runner queue wait from job execution time where timestamps are available.
- The operator UI or CLI can show whether a repo appears runner-capacity constrained.
- Discovery is read-only and cannot mutate runner setup.
Relationships
Related to #410 and #412. This should inform future merge-train scheduling but should not block the Level 1 merge train.
Validation
- Unit tests for runner inventory normalization and queue-wait calculations.
- Live read-only smoke against cbusillo/sellyouroutboard showing the three chris-testing lanes.
Decisions
- Start with awareness before control.
- Treat GitHub as the source of truth for runner registration/status.
- Treat host/container/service-level details as optional enrichment when Launchplane has access.
Open Questions
- Should runner inventory be stored as records, recomputed on demand, or both?
- How much host-level data should Launchplane collect without becoming a monitoring system?
Objective
Teach Launchplane to inventory and reason about self-hosted GitHub Actions runner lanes across managed repos.
Finish Line
Launchplane can report runner lanes and capacity signals without mutating runners
Current Status
State: Future work; not needed before the sequential merge train MVP, but useful before Launchplane starts making scheduling decisions across repos.
Next action: Design a runner-lane inventory record and a read-only discovery command/API.
Blocked by: None.
Last verified: 2026-05-07 after adding a third SYO runner lane manually on chris-testing.
Scope
Acceptance Criteria
Relationships
Related to #410 and #412. This should inform future merge-train scheduling but should not block the Level 1 merge train.
Validation
Decisions
Open Questions