CLICI/CD트러블슈팅GitHubActions

실패한 CI/CD 빌드의 근본 원인을 추적하는 CLI 프롬프트

개발자김철수2시간 전조회 3추천 0

변수 입력5개

CI_SYSTEM

RUN_URL_OR_LOG

BASE_SHA

HEAD_SHA

LOCAL_COMMAND

변수를 채운 뒤 완성본을 복사하세요

언제 사용하나

로컬에서는 통과하지만 CI에서 실패하거나, workflow의 여러 job 중 어디서 문제가 시작됐는지 알기 어려울 때 사용한다.

준비할 정보

{{CI_SYSTEM}}: GitHub Actions, GitLab CI 등
{{RUN_URL_OR_LOG}}: 실패 run URL 또는 secret을 제거한 로그
{{BASE_SHA}} / {{HEAD_SHA}}: 성공 기준과 실패 commit
{{LOCAL_COMMAND}}: 로컬 재현 명령

복사해서 쓰는 CLI agent 프롬프트

{{CI_SYSTEM}}의 실패를 증거 기반으로 진단해줘.
실패 run/log: {{RUN_URL_OR_LOG}}
성공 기준: {{BASE_SHA}}
실패 commit: {{HEAD_SHA}}
로컬 재현 명령: {{LOCAL_COMMAND}}

1. 저장소 지침과 workflow 파일을 읽고 job 의존성, runtime, service, cache, secret 요구사항을 요약해.
2. 로그의 마지막 줄만 보지 말고 첫 실패 단계와 이후 연쇄 실패를 분리해.
3. {{BASE_SHA}}..{{HEAD_SHA}} 변경 중 실패 단계에 영향을 줄 파일만 추려.
4. 버전, OS, locale, timezone, 파일시스템, network, cache 차이를 확인해.
5. 가설별로 가장 작은 재현 실험을 제시하고 한 번에 하나씩 실행해.
6. 원인이 확인되기 전에 cache 삭제, 재시도 추가, timeout 증가, 테스트 제거로 실패를 숨기지 마.
7. 수정이 필요하면 최소 diff와 회귀 테스트 계획을 먼저 보고하고 승인 범위 안에서만 수정해.

결과: '최초 실패 / 환경 차이 / 변경 영향 / 가설·실험 / 근본 원인 / 최소 수정 / 재현·회귀 검증'

검증 원칙

CI와 같은 runtime·package manager·lockfile로 재현한다.
실패한 job만 먼저 실행한 뒤 가능하면 전체 pipeline을 검증한다.
flaky 가능성이 있으면 성공 1회가 아니라 반복 횟수와 실패율을 기록한다.

중단 조건

secret이 필요하거나 외부 서비스에 write를 보내야 재현되는 경우, 배포·workflow rerun이 요금이나 외부 영향을 만드는 경우에는 승인을 받는다.