# 이 파일이 하는 일: push/PR 때마다 자동으로 백엔드 테스트 + 프론트 빌드를 돌리는 CI.
# 학습 포인트 — CI(지속적 통합)는 "사람이 깜빡해도 기계가 대신 검사하는 안전망"이다.
#   누가 코드를 밀 때마다 Gitea Actions 러너가 이 순서를 실행하고, 하나라도 실패하면
#   빨간 X로 알려 준다. 실제로 있었던 회귀(보안헤더로 문서 깨짐 등)를 조기에 잡는 그물이다.
# Gitea Actions는 GitHub Actions와 문법이 거의 같다 — 배운 걸 GitHub에서도 그대로 쓴다.
name: CI

on:
  push:
  pull_request:

jobs:
  # ── 백엔드: 단위 테스트 (규칙이 깨지면 여기서 빨간불) ──
  backend-test:
    runs-on: ubuntu-latest
    steps:
      - name: 코드 받기
        uses: actions/checkout@v4

      - name: Java 21 준비
        uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: "21"

      # mvnw 래퍼가 없어서 Maven을 내려받아 쓴다(작고 빠르다).
      # ⚠️ dlcdn(미러)은 최신 몇 버전만 두고 옛 버전을 지운다 — 3.9.9가 404로 사라져 CI가 깨졌었다.
      # archive.apache.org는 모든 버전을 영구 보관하므로 미래에도 안 깨진다. (-fSL은 실패 시 즉시 에러)
      - name: Maven 설치
        run: |
          curl -fsSL https://archive.apache.org/dist/maven/maven-3/3.9.9/binaries/apache-maven-3.9.9-bin.tar.gz -o /tmp/mvn.tgz
          tar xzf /tmp/mvn.tgz -C /opt
          echo "/opt/apache-maven-3.9.9/bin" >> "$GITHUB_PATH"

      # 포맷·위생 검사 (안 쓰는 import·줄끝 공백·파일끝 개행) — 어긋나면 여기서 빨간불.
      # 로컬에서 mvn spotless:apply 로 자동 교정 후 다시 밀면 통과.
      - name: 포맷 검사 (Spotless)
        run: |
          cd backend
          mvn -B -q spotless:check

      # 테스트 실행 + JaCoCo 커버리지 게이트(라인 30% 미만이면 실패 — 후퇴 방지 바닥).
      - name: 백엔드 테스트 + 커버리지
        run: |
          cd backend
          mvn -B -q test

  # ── 프론트: 빌드 (JSX 문법 오류·깨진 import를 잡는다) ──
  frontend-build:
    runs-on: ubuntu-latest
    steps:
      - name: 코드 받기
        uses: actions/checkout@v4

      - name: Node 22 준비
        uses: actions/setup-node@v4
        with:
          node-version: "22"

      - name: 의존성 설치
        run: cd frontend && npm ci

      # 의존성 취약점 스캔 — 배포에 실리는 패키지(--omit=dev)의 high 이상 취약점을 보고.
      # 학습 포인트 ①: package-lock.json 기반으로 레지스트리에 온디맨드 질의만 하므로(대용량 DB
      #   다운로드 없음) CI가 안정적이다. --omit=dev로 vite/eslint 등 배포에 안 실리는 도구는 제외.
      # 학습 포인트 ②: 왜 continue-on-error(비차단)인가? — npm audit는 "코드"가 아니라 "외부
      #   권고 DB 상태"에 결합된다. 우리가 한 줄도 안 고쳐도, 어느 날 axios 등에 새 권고가 뜨면
      #   차단형이면 무관한 PR까지 전부 CI가 붉어져 머지가 막힌다. 그래서 백엔드 OSV-Scanner와
      #   똑같이 도입 초기엔 "보고만" 하고, 팀이 수용목록(allow-list) 운영에 익숙해지면 차단으로 승격한다.
      - name: 의존성 취약점 스캔 (npm audit, 비차단)
        continue-on-error: true
        run: cd frontend && npm audit --omit=dev --audit-level=high

      # 린트: 안 쓰는 변수·존재하지 않는 전역·React 훅 오용 등 버그류 검출.
      - name: 린트 (ESLint)
        run: cd frontend && npm run lint

      # 테스트 + 커버리지 게이트(채점 로직 runSql.js 라인 40% 미만이면 실패).
      - name: 프론트 테스트 + 커버리지
        run: cd frontend && npm run coverage

      - name: 프론트 빌드 (JSX 오류·깨진 import 검출)
        run: cd frontend && npm run build

  # ── 백엔드 의존성 취약점 스캔 (OSV-Scanner) — 비차단(보고 전용) ──
  # 학습 포인트: 백엔드는 OWASP dependency-check의 NVD 대용량 DB를 클린 러너가 매 실행
  #   재다운로드해야 해(레이트리밋·타임아웃) CI를 불안정하게 만든다. 대신 OSV-Scanner는
  #   osv.dev에 패키지별 온디맨드 질의라 대용량 DB가 없다. 도입 초기라 continue-on-error로
  #   "보고만" 하고(취약점 있어도 CI는 초록), 팀이 익숙해지면 차단 게이트로 승격한다.
  backend-dep-scan:
    runs-on: ubuntu-latest
    steps:
      - name: 코드 받기
        uses: actions/checkout@v4

      # 릴리스 바이너리를 버전 고정으로 내려받는다(GitHub 릴리스 자산은 영구 보관 → 미래에도 안 깨짐).
      - name: OSV-Scanner 설치
        continue-on-error: true
        run: |
          curl -fsSL https://github.com/google/osv-scanner/releases/download/v2.4.0/osv-scanner_linux_amd64 -o /usr/local/bin/osv-scanner
          chmod +x /usr/local/bin/osv-scanner

      - name: 백엔드 pom.xml 취약점 스캔 (비차단)
        continue-on-error: true
        run: osv-scanner scan source -r backend