셀프호스티드 러너 잡이 queued에서 안 잡힌다면, 대개 라벨 아니면 용량이다
잡이 계속 대기 상태라면 러너가 “이 잡을 내가 맡을 수 있다”고 판단하지 못한 것이다. 순서대로 본다.
1) 라벨이 정확히 매칭되지 않는다
runs-on: [self-hosted, linux, gpu]는 세 라벨을 모두 가진 러너를 요구한다. 러너 등록 라벨에 하나라도 빠지거나 대소문자가 다르면(GPU vs gpu) 영원히 대기한다. 워크플로의 라벨과 러너 등록 라벨을 나란히 비교한다.
2) 러너가 오프라인이다
Settings → Actions → Runners에서 상태가 Idle이어야 잡을 받는다. Offline이면 러너 머신의 서비스가 죽었거나 GitHub로 아웃바운드가 막힌 것이다.
sudo ./svc.sh status # 러너 서비스 상태
journalctl -u actions.runner.* --tail=100
3) 용량이 부족하다(전부 busy)
러너 수보다 동시 잡이 많으면 나머지는 대기한다. 라벨을 만족하는 러너가 모두 다른 잡을 돌리는 중인지 본다. 이 경우 러너를 늘리거나 동시성(concurrency)을 조절한다.
4) 러너 그룹 권한
러너가 특정 runner group에 속하고 그 그룹이 이 리포지터리/조직에 접근을 허용하지 않으면, 온라인이어도 잡이 배정되지 않는다. 그룹의 리포 접근 설정을 확인한다.
정리
라벨 정확 매칭 → 러너 Idle/온라인 → 용량(busy) → 러너 그룹 권한. 가장 흔한 건 라벨 오타 하나이므로, 워크플로 runs-on과 러너 라벨을 글자 단위로 대조하는 것으로 시작한다.
빠른 진단 체크리스트
- 워크플로 runs-on 라벨과 러너 등록 라벨을 글자 단위로 대조한다
- 세 라벨을 모두 가진 러너가 있어야 매칭됨을 기억한다
- 대소문자 불일치(GPU vs gpu)도 매칭을 깬다
- Settings의 러너 상태가 Idle(온라인)인지 확인한다
- 러너 머신의 서비스·아웃바운드가 살아 있는지 본다
- 라벨을 만족하는 러너가 전부 busy(용량 부족)인지 본다
- 필요하면 러너를 늘리거나 concurrency를 조절한다
- 러너 그룹이 이 리포·조직에 접근을 허용하는지 확인한다