I Fixed The Bug. Then My Pipeline Refused to Run.
버그를 고쳤는데 파이프라인이 실행되지 않았습니다
Terraform 오류를 고친 뒤에도 GitLab 파이프라인이 시작되지 않았습니다. 원인은 코드가 아니라 월간 compute minutes 소진이었고, 글쓴이는 사용량 확인 권한과 CI 비용을 줄이는 설정을 정리합니다.
- 주제
에디터 노트
이 사례에서 막힌 지점은 Terraform 코드가 아니라 파이프라인 실행 quota와 사용량을 확인할 권한이었습니다. 로그가 없고 작업이 시작되지 않았다는 단서가 코드 오류와 계정 한도 문제를 가르는 기준으로 제시됩니다. 그룹 Owner만 사용량을 볼 수 있다는 설명은 개발자가 혼자 해결하기 어려운 이유도 보여줍니다. 변경 파일에 따른 작업 실행, 중복 파이프라인 취소, 캐시 사용은 반복되는 CI 소비를 줄이는 설정입니다. 다만 글은 각 설정으로 compute minutes가 얼마나 절감되는지 수치로 제시하지 않습니다. 자체 관리 runner도 팀에 서버가 있고 운영할 여건이 있을 때 쓸 수 있는 선택지로 소개합니다. 댓글이 없어 다른 팀의 quota 정책이나 경험은 비교할 수 없습니다.
AI 요약
인턴으로 Terraform 데이터베이스 배포 오류를 해결한 뒤에도 GitLab 파이프라인은 실행되지 않았습니다. 7개 작업 중 5개가 실패로 표시됐지만 로그나 스택 트레이스는 없었습니다. 원인은 월간 compute minutes를 모두 쓴 것이었습니다.
오류 확인과 해결
작업이 시작되기 전 quota가 소진되면 로그 없이 실패할 수 있습니다. 재시도해도 사용량이 복구되기 전까지는 같은 문제가 이어집니다. 글쓴이가 본 "Status cannot transition via drop" 오류도 시작하지 못한 작업의 상태를 GitLab이 갱신하지 못하면서 나타난 것으로 설명합니다. 사용량 확인에는 그룹 Owner 권한이 필요해, 글쓴이는 계정 관리 담당자에게 quota 확인과 충전을 요청했습니다.
사용량을 줄이는 방법
GitLab 사용량은 매월 초기화되며, 버전 16.1부터 "CI/CD minutes"라는 명칭이 "compute minutes"로 바뀌었습니다. 글쓴이는 변경된 파일에 해당하는 작업만 실행하는 rules: changes 설정, 브랜치와 merge request에서 중복 파이프라인을 막는 workflow: rules, 새 커밋이 오면 이전 작업을 취소하는 interruptible 설정과 자동 취소를 제안합니다. 반복해서 내려받는 의존성과 Terraform provider를 캐시하고, 매번 실행할 필요가 없는 작업은 수동으로 돌리는 방법도 있습니다. GitLab 문서에 따르면 자체 관리 runner는 compute quota에 포함되지 않습니다.
원문: dev.to / 번역·요약: Trawling