테스트를 통과시켰지만 근거가 틀렸습니다 — 리뷰가 잡아낸 두 건
경로를 잘못 단정하던 테스트를 고쳤는데, 리뷰가 제 수정의 근거를 무너뜨렸습니다. 검색 결과의 첫 히트를 근거로 삼았고, 그것은 제가 찾던 것과 이름만 같은 다른 값이었습니다.
경로를 잘못 단정하던 테스트를 고쳤는데, 리뷰가 제 수정의 근거를 무너뜨렸습니다. 검색 결과의 첫 히트를 근거로 삼았고, 그것은 제가 찾던 것과 이름만 같은 다른 값이었습니다.
윈도우 러너에 무거운 작업을 맡길 수 없다고 믿었는데, 막고 있던 것은 성능이 아니라 코드베이스가 리눅스를 전제하고 쓴 문법이었습니다. 그리고 그날 내린 보류 결정은 지적 한 줄에 그날 무너졌습니다.
윈도우 러너가 느린 범인을 파일시스템으로 지목했는데, 그것도 절반만 맞았습니다. 파일 16만 개짜리 폴더를 93만 개 경로로 걷게 만든 것은 패키지 매니저의 링크 구조였고, 설정 한 줄로 260초가 14초가 됐습니다.
의존성 캐시를 끄자 작업당 4분이 사라졌습니다. 캐시는 매번 새로 만들어지는 기계를 전제로 설계된 장치인데, 제 러너는 사라지지 않는 기계였습니다. 전제가 다르면 최적화는 순손실이 됩니다.
전기세를 아끼려고 CI 러너 노트북을 재웠다가 깨우지 못했습니다. RTC 알람도 WoL 매직패킷도 무응답이었고, 설정은 전부 켜져 있었습니다. 결국 밤중에 전원 버튼을 누르러 간 이야기입니다.
사용량을 총량으로만 보면 원인이 안 보입니다. 저장소별 SKU로 분해하자 raw 99.4분짜리 macOS 작업이 994분으로 청구돼 쿼터의 절반을 태우고 있었습니다. 2주간 만든 러너 함대는 그래서 전부 껐습니다.
윈도우 러너가 hosted보다 15배 느렸습니다. 공유기가 100Mbps라는 증거까지 찾아내 네트워크를 범인으로 지목했는데, 캐시가 채워진 상태의 재측정이 콜드보다 느리면서 진단이 통째로 뒤집혔습니다.
맥북 한 대로는 CI 큐가 밀렸습니다. 방치돼 있던 Proxmox 홈랩 서버와 윈도우 노트북을 러너로 붙이면서, 네이티브 폴백이 없는 GitHub Actions에서 라벨만으로 폴백을 만든 과정을 정리합니다.
GitHub Actions hosted 러너가 새벽에 전면 차단됐습니다. 변수 한 줄과 self-hosted 러너로 30분 만에 우회했지만, 에러 메시지를 원인으로 착각한 탓에 진짜 이유는 2주 뒤에야 알게 됐습니다.