CI/CD2분 읽기· 연습 문제 3개

self-hosted runner job이 queued에서 멈출 때

runner는 등록되어 보이지만 label, group, network, token 문제로 job을 가져오지 못하는 상황에서 먼저 볼 신호, CLI 확인 순서, 흔한 오진, 안전한 복구 방향을 정리한 InfraTree 가이드입니다.

목차
  1. 셀프호스티드 러너 잡이 queued에서 안 잡힌다면, 대개 라벨 아니면 용량이다
  2. 1) 라벨이 정확히 매칭되지 않는다
  3. 2) 러너가 오프라인이다
  4. 3) 용량이 부족하다(전부 busy)
  5. 4) 러너 그룹 권한
  6. 정리
  7. 빠른 진단 체크리스트

셀프호스티드 러너 잡이 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를 조절한다
  • 러너 그룹이 이 리포·조직에 접근을 허용하는지 확인한다

이 가이드로 연습하기

같은 장애를 다룬 검수된 문제입니다. 원인·복구·재발 방지를 직접 적어 보고 모범 풀이와 비교해 보세요.

다음에 읽을 가이드