AWESOMEDEV c723cba92c

CI / backend-test (push) Successful in 51s

Details

CI / frontend-build (push) Successful in 17s

Details

test: 배포 스모크 테스트 (deploy/smoke-test.sh) — 인프라·설정 회귀 감지

CI가 못 잡는 '설정 회귀'(예: 보안헤더로 문서 iframe 깨짐)를 배포 후 잡는 그물.
살아있는 사이트를 실제 사용자처럼 두드려 11개 확인:
- 홈 200, HTTP→HTTPS 리다이렉트, 보안헤더 3종
- 학습 문서 200 + X-Frame-Options=SAMEORIGIN + no-cache + 한국어 본문
  (그 회귀를 정확히 재현·감지)
- 백엔드 API 401(Caddy→백엔드→DB 경로), SPA 라우트 폴백
하나라도 실패 시 exit 1. CI.md에 사용법·권장 배포 흐름 문서화.

운영 검증: 11/11 통과, exit 0.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-17 17:39:27 +09:00

4.3 KiB

Raw Blame History

CI — Gitea Actions (push 시 자동 테스트)

push/PR마다 백엔드 테스트 + 프론트 빌드를 자동으로 돌려, 회귀를 배포 전에 잡는다. 워크플로 정의: .gitea/workflows/ci.yml

구성 요소

요소	위치	역할
Actions 활성화	`docker-compose.prod.yml` gitea env `GITEA__actions__ENABLED=true`	Gitea에 Actions 기능 켜기
러너(runner)	compose 서비스 `runner`(`gitea/act_runner`)	일감을 받아 job 컨테이너를 띄우는 일꾼
러너 설정·등록	호스트 `/opt/mirim-runner/` (`config.yaml`, `.runner`)	최초 등록 정보·job 컨테이너 네트워크 설정
워크플로	`.gitea/workflows/ci.yml`	무엇을 검사할지(백엔드 test, 프론트 build)

동작 흐름

누가 push하면 Gitea가 워크플로를 큐에 넣는다.
러너가 job을 받아 catthehacker/ubuntu:act-22.04 이미지로 job 컨테이너를 띄운다.
job 컨테이너는 deploy_default 네트워크 + --add-host edu.awesomedevapp.com:host-gateway로 Gitea에서 코드를 clone한 뒤, 백엔드 mvn test / 프론트 npm ci && npm run build를 실행한다.
하나라도 실패하면 커밋에 빨간 X, 다 통과하면 초록 체크가 붙는다. (Gitea 웹 → Actions 탭)

러너를 처음부터 다시 세워야 한다면

# 1) Actions 활성화 (compose env, 이미 되어 있음) 후 gitea 재기동
# 2) 등록 토큰 발급
sudo docker exec -u git mirim-gitea gitea --config /data/gitea/conf/app.ini actions generate-runner-token

# 3) 설정 파일 (/opt/mirim-runner/config.yaml)
#    labels: ubuntu-latest → catthehacker/ubuntu:act-22.04
#    container.network: deploy_default
#    container.options: --add-host=edu.awesomedevapp.com:host-gateway   ← job이 Gitea에 clone하려면 필수
# 4) 최초 1회만 토큰으로 등록 (등록되면 .runner 생성, 이후 compose가 관리)
sudo docker run --rm --network deploy_default \
  -v /var/run/docker.sock:/var/run/docker.sock -v /opt/mirim-runner:/data -w /data \
  -e GITEA_INSTANCE_URL=http://mirim-gitea:3000 \
  -e GITEA_RUNNER_REGISTRATION_TOKEN=<토큰> -e CONFIG_FILE=/data/config.yaml \
  gitea/act_runner:0.2.11
# 5) compose로 상시 실행
sudo docker compose -f deploy/docker-compose.prod.yml up -d runner

함정 메모 (겪은 것)

Maven 다운로드: dlcdn 미러는 옛 버전을 지운다(3.9.9가 404로 사라져 CI가 깨졌었다). → 모든 버전을 영구 보관하는 archive.apache.org를 쓴다.
clone 실패: job 컨테이너가 Gitea(edu.awesomedevapp.com:3000)에 못 닿으면 checkout이 실패한다. → --add-host edu.awesomedevapp.com:host-gateway로 컨테이너에서 호스트(→ 게시된 3000)로 잇는다.
actions/checkout은 node 필요: job 이미지에 node가 있어야 한다(catthehacker 이미지에 포함). 그래서 백엔드 job도 이 이미지를 쓰고 Maven만 따로 내려받는다.

배포 스모크 테스트 (`deploy/smoke-test.sh`)

CI는 "코드"를 배포 전에 검사한다. 하지만 실제로 났던 사고(보안헤더로 학습 문서 iframe이 안 뜬 것)는 코드가 아니라 Caddy 설정 문제라 CI 테스트로는 안 잡혔다. 스모크 테스트는 배포된 살아있는 사이트를 실제 사용자처럼 두드려, 설정·헤더·인프라까지 포함해 "정말 열리는가"를 확인한다. → CI(코드 그물) + 스모크(설정·운영 그물).

# 배포 직후 반드시 실행 — 하나라도 실패하면 exit 1
bash deploy/smoke-test.sh

검사 항목(11): 홈 200 · HTTP→HTTPS 리다이렉트 · 보안헤더 3종 · 학습 문서 200 + X-Frame-Options=SAMEORIGIN + no-cache + 한국어 본문(그 회귀를 직접 감지) · 백엔드 API 401(Caddy→백엔드→DB 경로) · SPA 라우트 폴백.

권장 배포 흐름: 빌드 → 업로드 → docker compose up → bash deploy/smoke-test.sh. 스모크가 빨간불이면 배포에 문제가 있는 것이니 바로 롤백/수정한다.

다음 개선 (학생 티켓)

Maven·npm 캐시로 CI 실행 시간 단축
main 브랜치 보호(테스트 통과해야 merge)
스모크 테스트를 배포 스크립트에 자동 편입(deploy 후 자동 실행·실패 시 알림)

4.3 KiB Raw Blame History