forgejo runner pinned to offline kai-desktop-tower-wsl - docker-label CI queue starves #312
Labels
No labels
burndown-2026-06
coherence-core
consult
headless
interactive
P0
P1
P2
P3
P4
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
coilyco-flight-deck/infrastructure#312
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
eco-app CI run #3 (and likely all docker-label jobs) sits in "Waiting to run" indefinitely. Tailscale shows the runner host offline:
kai-desktop-tower-wsl- offline, last seen 6 days agokai-desktop-tower- offline, last seen 6 days agokai-tower-3026/kai-tower-3026-wsl- activeThe forgejo runner StatefulSet is deliberately pinned to
kai-desktop-tower-wsl(per docs/k3s-deploy-notes.md, to keep DinD bridge churn off kai-server). With the tower replaced by kai-tower-3026, the pin is stale: runner pods cannot schedule and the queue starves.Fix path:
kai-tower-3026-wslto the k3s cluster (if not already) and repin the runner StatefulSet's nodeSelector to it.local-pathPVCs from the old node so the StatefulSet can recreate them (known trap in the deploy notes triage tree).Found while shipping the first eco-app rollout (2026-06-12); the rollout proceeded by building the image on kai-server directly.
Update from the eco-app rollout (same day): the queue drained itself before any repin.
kubectl get nodesduring the rollout showed the cluster is now single-node (kai-server only) - the tower node is not in the cluster at all - andforgejo-runner-0/forgejo-runner-1were Running on kai-server, ~7 minutes old with 3 restarts, right before eco-app CI run #3 went green and published the image.So the original framing (stale nodeSelector pin to kai-desktop-tower-wsl) does not match the live cluster: either the pin was already removed, or the StatefulSet tolerates kai-server now. What remains of this issue:
kai-tower-3026-wslby joining it to the cluster, or consciously accept the kai-server placement and update the notes.