GitHub Actions CI가 느린 이유 (그리고 ... 노트

GitHub Actions CI가 느린 이유 (그리고 속도를 높이는 방법)

GitHub에서 최근 발생한 데이터베이스 백업 실패는 흔한 문제, 즉 느리거나 실패하는 CI 워크플로우를 부각시켰습니다. 명백한 실패와 달리, 느린 실행은 종종 눈에 띄지 않아 리소스 낭비로 이어집니다. 인기 있는 오픈 소스 저장소를 스캔한 결과, CI 구성에서 광범위한 비효율성이 발견되었습니다. 많은 프로젝트에서 동시성 제어 및 작업 시간 초과와 같은 중요한 설정이 누락되어 중복 워크플로우가 발생했습니다.주요 문제 중 하나는 푸시와 풀 리퀘스트 모두에서 워크플로우를 트리거하여 동일한 변경 사항에 대해 중복 실행을 유발하는 것입니다. 이는 기본 브랜치를 제외하고 풀 리퀘스트에서만 트리거하도록 하여 해결할 수 있습니다. 또 다른 흔한 문제는 새로운 코드가 푸시될 때 진행 중인 실행을 취소하지 못하여 낭비되는 큐 슬롯을 초래하는 것입니다. cancel-in-progress를 true로 설정한 동시성 그룹을 구현하면 이를 방지할 수 있습니다.매번 실행 시 종속성을 처음부터 다시 설치하는 것도 상당한 시간을 추가합니다. 설정 작업에서 캐싱 기능을 활용하면 이 프로세스를 크게 가속화할 수 있습니다. 너무 큰 행렬, 모든 OS 버전 조합에 대한 테스트는 풀 리퀘스트에 대해 더 슬림한 행렬을 실행하고 기본 브랜치 또는 야간 빌드에 대해 전체 행렬을 실행하여 최적화할 수 있습니다. CI 트리거를 특정 파일 경로로 범위 지정하지 않으면 문서의 오타와 같은 모든 변경 사항도 전체 테스트 스위트를 트리거할 수 있습니다.또한, 시간 초과가 없는 작업은 몇 시간 동안 중단되어 과도한 리소스를 소비할 수 있습니다. 각 작업에 대해 timeout-minutes를 설정하는 것이 필수적입니다. 이러한 일반적인 CI 비효율성을 식별하기 위해 공개 저장소를 스캔하는 도구를 사용할 수 있습니다. 인기 있는 프로젝트의 Actions 점수표를 확인하는 것도 모범 사례에 대한 통찰력을 제공할 수 있습니다. 저자는 공개 저장소에서 이러한 패턴을 식별하는 데 도움이 되는 무료 스캐너를 제공합니다.