| name | fix-ci-until-green |
| description | 이 브랜치의 가장 최근 실패한 CI 실행을 gh로 가져와 로그를 읽고, 로컬에서 똑같이 재현한 뒤 근본 원인을 최소 diff로 고치고 push해서, 체크가 다시 green이 될 때까지 반복하는 닫힌 루프입니다. 사용자가 "CI 빨간불 고쳐줘", "CI 통과할 때까지 고쳐줘", "깨진 CI 초록불 만들어줘", "CI 실패 원인 찾아서 고쳐줘", "GitHub Actions 실패 고쳐", "fix CI until green", "fix the failing CI", "make CI pass", "get the build green"처럼 원격 CI가 빨갛게 떠 있어 그걸 직접 고쳐 통과시키고 싶을 때 사용하세요. (구분: 주기적으로 CI를 폴링하며 감시·자동 수정하는 건 looping:ci-failure-watcher, 구현부터 PR을 열고 머지 가능 상태까지 끌고 가는 건 looping:ship-pr-until-green, 원격이 아니라 로컬 테스트 스위트를 green까지 돌리는 건 looping:test-until-green, 프로덕션 빌드 컴파일 에러를 고치는 건 looping:build-until-green) |
CI 초록불까지 고치기 (Fix CI Until Green)
가장 최근 실패한 CI 실행을 가져와 로컬에서 재현하고, 고치고, 체크가 통과할 때까지 반복합니다.
| 항목 | 값 |
|---|
| 카테고리 | CI |
| 트리거 | 수동(manual) — 사람이 직접 시작 |
| 종료 조건(Exit) | 이 브랜치 최신 CI 실행의 결론(conclusion)이 success일 때 |
| 반복 한도(Max iterations) | 8 |
| 매 반복 체크 명령 | gh run list --branch $(git branch --show-current) --limit 1 --json conclusion -q '.[0].conclusion' |
| 가드레일 | 강화됨(Hardened) |
| 지원 에이전트 | Claude Code · Cursor |
이 루프는 언제 쓰나
푸시는 했는데 GitHub Actions(또는 다른 CI)가 빨갛게 떠 있고, "로그 까보고 → 로컬에서 재현하고 → 고치고 → 다시 push해서 확인"을 빨간불이 사라질 때까지 손으로 왕복하기 지칠 때 씁니다. 한 번 시작하면 에이전트가 gh로 가장 최근 실패 실행만 집어서 로그를 읽고, 로컬에서 동일한 단계를 재현해 근본 원인을 최소 diff로 고친 뒤, push하고 CI 결과를 다시 확인하는 사이클을 스스로 돕니다. 핵심은 재현 없이 추측으로 고치지 않는 것 — 로컬에서 실패를 먼저 재현해야 진짜 원인을 잡고 무관한 리팩터로 새 실패를 만들지 않습니다.
루프 흐름
수동 시작 → 실패 실행 가져오기 → 로컬 재현 → 수정 적용 → push & 확인 →〔피드백 게이트〕최신 실행이 success?
↑ │ 아니오
└────────────────────────────────────────────────────────────────────────┘
│ 예
종료
매 반복(pass)마다 하는 일
- 실패 실행 가져오기 —
gh로 이 브랜치의 가장 최근 실패한 CI 실행을 찾고, 실패한 잡(job)의 로그를 끌어옵니다.
gh run list --branch $(git branch --show-current) --status failure --limit 1
- 로컬 재현 — 실패한 CI 단계(test, lint, build)를 로컬에서 그대로 돌려 에러가 재현되는지 확인합니다.
- 수정 적용 — 근본 원인을 최소 diff로 고칩니다. 무관한 리팩터는 피하세요.
- push & 확인 — 수정을 push하고 CI를 기다립니다. 다음 반복 전에 상태를 다시 확인합니다.
gh run list --branch $(git branch --show-current) --limit 1 --json conclusion -q '.[0].conclusion'
가드레일 (점수 조작 방지 규칙)
종료 조건을 "가짜로" 통과시키지 못하게 막는 규칙입니다. 반드시 지키세요.
- 체크 명령이나 종료 기준을 고쳐서 억지로 성공시키지 않는다.
- 체크를 건너뛰거나 비활성화·우회해서 종료 조건을 통과시키지 않는다.
- 여러 번 반복해도 막히면, 지표를 조작하지 말고 멈추고 블로커를 보고한다.
Claude Code에서 실행하기
가장 간단합니다. 아래 kickoff 프롬프트를 그대로 붙여넣으면 에이전트가 스스로 반복합니다.
"CI 초록불까지 고치기(Fix CI Until Green)" 루프를 시작합니다.
목표: 이 브랜치의 최신 CI 실행이 통과
최대 반복: 8
매 반복 사이 실행: gh run list --branch $(git branch --show-current) --limit 1 --json conclusion -q '.[0].conclusion'
종료 조건: 최신 실행 결론(conclusion)이 success일 때
1단계: 가장 최근 실패한 CI 실행을 찾아 로그를 읽고, 로컬에서 재현하고, 근본 원인을 고쳐 push한 뒤 검증한다.
이 루프를 스스로 페이싱(self-pace)하라. 매 반복 후 체크 명령을 실행하고 출력을 읽어, 종료
조건이 충족되지 않았을 때만 계속한다. 종료 조건이 통과하거나 최대 반복에 도달하면 멈춘다.
매 회차마다 한 줄 상태 업데이트를 남긴다.
전제: gh CLI가 설치·인증되어 있어야 하고(gh auth status로 확인), 현재 브랜치가 원격에 push되어 CI 실행 기록이 있어야 합니다.
팁 / 변형
- 다른 CI 생태계로: 체크 명령은 GitHub Actions +
gh 기준입니다. GitLab은 glab ci status, CircleCI는 circleci/API 등으로 바꾸고, "로컬 재현" 단계의 명령도 프로젝트 실패 단계(npm test, pytest, cargo test, go build ./... 등)에 맞추세요.
- 재현이 안 될 때: 로컬에서 재현이 안 되면 CI 전용 환경 차이(노드 버전, 환경변수, 캐시, OS)를 먼저 의심하고, CI 로그의 정확한 단계·명령을 그대로 재현하게 하세요. 추측으로 고치고 push해서 한도를 낭비하지 않는 게 핵심입니다.
- 막힐 때: 같은 실패가 2회 반복되면 가드레일대로 멈추고, 원인 가설과 함께 사람에게 보고하게 하세요.
- 연관 루프: 주기적으로 CI를 감시하려면
looping:ci-failure-watcher, PR을 열어 머지까지 가려면 looping:ship-pr-until-green, 로컬 테스트만 green까지 돌리려면 looping:test-until-green.
원본 영어 kickoff (loops.elorm.xyz 원문)
Start the "Fix CI Until Green" loop.
Goal: latest CI run on this branch passes
Max iterations: 8
Between iterations run: gh run list --branch $(git branch --show-current) --limit 1 --json conclusion -q '.[0].conclusion'
Exit when: latest run conclusion is success
Step 1: Find the latest failed CI run, read logs, reproduce locally, fix root cause, push, and verify.
Self-pace this loop. After each iteration, run the check command, read the output, and only continue if the exit condition is not met. Stop when the exit condition passes or max iterations is reached. Give a short status update each pass.
출처: https://loops.elorm.xyz/loops/fix-ci-until-green
