测验：失败分类与缩小原因范围

파이프라인 실패를 갈래로 나누지 않을 때 생기는 가장 큰 문제는?

• 실패 로그가 쌓여 산출물 저장 공간을 빠르게 소진한다
• 재시도 횟수가 늘어 러너 사용 시간이 크게 증가한다
• 실패 통계를 대시보드에 나눠 표시할 수 없게 된다
• 전부 재시도로 대응하게 되어 진짜 결함이 그 안에 숨는다

불안정한 시험과 진짜 결함을 가르는 가장 직접적인 방법은?

• 실패 로그에 나온 예외 종류가 코드 결함 유형인지 살펴본다
• 같은 커밋을 다시 돌려 결과가 갈리는지 본다
• 최근 변경된 파일과 실패한 시험의 경로가 겹치는지 본다
• 실패한 시험의 평균 실행 시간이 늘었는지 비교한다

무작위 순서로 시험을 돌리는 러너가 반드시 로그에 남겨야 하는 것은?

• 그 실행에 쓴 난수 씨앗과 그것을 다시 넣는 방법
• 시험 파일들이 디스크에 저장된 절대 경로 목록
• 각 시험이 사용한 메모리 최대치와 CPU 시간
• 실행을 시작한 러너의 호스트 이름과 IP 주소

git bisect run 이 쓰는 판정 스크립트에서 종료 코드 125의 뜻은?

• 이 커밋이 문제의 원인임을 확정하고 탐색을 끝낸다
• 이 커밋은 정상이므로 더 나중 구간을 탐색한다
• 이 커밋은 판정할 수 없으므로 건너뛴다
• 이 커밋에서 오류가 나 탐색 자체를 중단한다

자동 이분 탐색을 돌리기 전에 반드시 확인해야 할 조건은?

• 판정 스크립트가 같은 커밋에서 언제나 같은 답을 내는가
• 탐색 구간의 커밋 수가 2의 거듭제곱에 가까운가
• 판정 스크립트가 60초 안에 끝나도록 최적화됐는가
• 탐색 구간 안의 모든 커밋이 빌드에 성공하는가

되먹임 시간 예산을 넘겼을 때 단계를 조정하면서 함께 해야 할 일은?

• 실행 시간이 가장 긴 시험 파일을 목록에서 제거한다
• 재시도 횟수를 늘려 실패한 단계가 다시 돌게 한다
• 러너를 늘려 모든 단계를 동시에 시작하도록 바꾼다
• 무엇을 포기했는지 기록해 나중에 설명할 수 있게 한다