Timeout

~8 min · timeout, hangs, reliability

Level 0견습생

0 XP0/101 lessons0/10 achievements

0/120 XP to next level120 XP to go0% complete

기본 6시간 작업 타임아웃은 거의 모든 상황에 어긋나

명시적으로 타임아웃을 정하지 않으면 작업이 최대 6시간까지 돌아. 불안정한 외부 서비스를 기다리는 테스트나 레지스트리 장애로 막힌 docker pull처럼 멈춰버린 프로세스가 반나절 동안 CI 예산을 조용히 갉아먹을 수 있어.

타임아웃을 빡빡하게 설정하자:

작업 수준 timeout-minutes: — 전체 작업의 상한선이야.
단계 수준 timeout-minutes: — 개별 단계의 상한선이야.

합리적인 기본값

작업 유형	합리적인 상한선
린트 / 포맷	5분
유닛 테스트	10-15분
통합 / e2e	30-45분
배포	15-30분
릴리스 파이프라인	60분

작업이 상한선에 도달하면 실행이 실패해. 이게 맞는 동작이야. 왜 그렇게 오래 걸렸는지 조사해봐야지.

Code

작업 + 단계 타임아웃·yaml

  test:
    runs-on: ubuntu-latest
    timeout-minutes: 15        # whole-job cap
    steps:
      - uses: actions/checkout@v4
      - run: pip install -e '.[dev]'
        timeout-minutes: 5     # install must not hang
      - run: pytest -q
        timeout-minutes: 10    # tests must complete in 10

External links

GitHub — 작업 및 단계 타임아웃

Exercise

워크플로의 모든 작업에 timeout-minutes를 추가해. 최근 p95 실행 시간의 1.5배를 상한선으로 잡아. 푸시하고 몇 번 실행해봐서 잘려나가는 게 없는지 확인해.

Progress

Progress is local-only — sign in to sync across devices.

← PreviousConcurrency Next →오류가 나도 계속 진행하기

이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

🔔 답글 알림 (로그인 필요)

로그인 — 댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.