러너 환경에서 잡이 간헐적으로 멈추는 것을 확인했다.
Flutter 잡이 CPU 0%·네트워크 정지 상태로 25분 넘게 러너를 점유해
이후 잡들이 시작조차 하지 못했다. Frontend 잡에서도 같은 증상이 나타났다.
러너가 하나뿐이면 멈춘 잡 하나가 이후 전부를 굶긴다.
워크플로를 분리해도 점유 자체는 막지 못하므로 상한이 필요하다.
- backend 20분 / frontend 15분 / error-codes-sync 10분 / flutter 25분
- 증상과 즉시 해제 방법(잡 컨테이너 중지)을 ci/README.md 에 정리
CI 작성 시 넣었어야 할 기본 안전장치를 빠뜨렸던 것을 보완한다.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Flutter 잡은 SDK 다운로드로 매 실행 수 분이 걸리는데,
backend/frontend 만 고친 커밋에서는 검사할 것이 없다.
러너가 잡을 하나씩 처리하므로 다른 검사까지 같이 느려졌다.
ci-flutter.yml 로 분리하고 flutter/ 경로가 바뀐 푸시·PR 에서만 실행되게 한다.
실제로 모바일 앱을 쓰기 시작하면 별도 설정 없이 자동으로 동작하고,
그 전까지는 CI 시간을 차지하지 않는다. workflow_dispatch 로 수동 실행도 가능하다.
Redis 를 compose profile 로 기본 비활성화한 것과 같은 방향이다 —
기반은 갖춰두되 쓰지 않을 때는 자원을 차지하지 않게 한다.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
러너를 붙이고 첫 실행에서 backend 잡의 모든 스텝이 checkout 부터 failure 로 표시됐다.
스텝이 실패한 게 아니라 서비스 컨테이너가 뜨지 못해 잡 준비 단계에서 죽은 것이다.
원인은 postgres 서비스의 ports: 5432:5432 였다.
개발 DB(project-db)가 이미 호스트 5432 를 점유하고 있어 바인딩이 충돌했다.
Gitea 러너는 잡을 컨테이너로 실행하고 서비스와 같은 네트워크에 붙이므로
호스트 포트 매핑이 애초에 필요 없고, 접근도 localhost 가 아니라 서비스 이름으로 해야 한다.
(GitHub Actions 는 잡이 VM 위에서 직접 돌아 localhost + ports 를 쓰는 점이 다르다)
- 서비스의 ports 매핑 제거
- e2e 스텝의 DB_HOST 를 localhost → postgres(서비스 이름)로 변경
- 두 플랫폼의 차이와 "모든 스텝이 한꺼번에 실패" 증상을 ci/README.md 에 정리
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
CI 워크플로는 저장소에 있지만 실행 주체(러너)가 없어 동작하지 않는 상태였다.
러너가 없으면 워크플로는 "Waiting for a runner" 로 대기만 한다.
- ci/docker-compose.runner.yml — act_runner 를 별도 스택으로 분리.
앱 스택은 개발할 때만 띄우지만 러너는 항상 켜져 있어야 하므로 생명주기가 다르다.
- ci/.env.example — 등록 토큰은 ci/.env 에만 두며 커밋되지 않는다.
- ci/README.md — 설치 절차, 증상별 문제 해결, 잡별 리소스 특성.
- 라벨 기본값이 워크플로의 runs-on(ubuntu-latest)과 일치하는지 교차 확인했다.
불일치는 잡이 영원히 대기하는 가장 흔한 원인이다.
러너가 도커 소켓에 접근해 사실상 호스트 관리자 권한을 갖는다는 점도 문서에 명시했다.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ttipo