GitHub Actions and Worker Debugging

Why GitHub Actions is Hard to Debug

이유	설명
Ephemeral VM	실행이 끝나면 서버가 사라짐
상태 없음	로컬처럼 파일·DB·환경을 못 봄
로그만 존재	stdout/stderr만 남음
비결정성	API, 네트워크, 타이밍 차이
Step 단위 실패	어느 명령이 죽었는지 모호

Essential Settings

Step Debug Mode

env:
  ACTIONS_STEP_DEBUG: true
  ACTIONS_RUNNER_DEBUG: true

Bash Strict Mode

set -euxo pipefail

CI 스크립트 맨 위에 넣어야 함.

Shell First Structure

❌ Bad

- run: pnpm test
- run: wrangler deploy
- run: python crawl.py

✅ Good

- run: .github/scripts/ci.sh

→ 로컬에서 이걸 실행하면 CI와 100% 동일

tmate SSH (실패 시 디버깅)

- name: Setup tmate session
  uses: mxschmitt/action-tmate@v3

CI가 실패하면 ssh xxx@tmate.io로 실패한 CI 서버에 직접 로그인 가능.

Cloudflare + Workers Architecture

GitHub Actions는 트리거만 해야 합니다.

GitHub Action
   ↓
Call Ingress Worker
   ↓
Queue
   ↓
Consumer Workers

CI가 크롤링·AI·DB·배포를 직접 하면 디버깅 지옥이 됩니다.

Recommended Flow

GitHub Push
   ↓
GitHub Action
   ↓
ci.sh (로컬과 동일)
   ↓
wrangler --dry-run
   ↓
wrangler deploy preview
   ↓
Queue trigger
   ↓
Cloudflare Workers

Logpush for Evidence

Worker에 버전·빌드 정보 로깅:

const VERSION = "2026-01-27T1028Z";
const BUILD = "git-<commit-hash>";

export default {
  fetch(req, env, ctx) {
    console.log("deploy", VERSION, BUILD);
    console.log("request", req.method, new URL(req.url).pathname);
  }
}

→ Cloudflare Logpush → R2 / Datadog / Logflare