Logpush CI Failure Analysis
코드 수정 없이 문제점 분석과 해결안 기획만 기술.
1. 로그에서 보이는 에러
섹션 제목: “1. 로그에서 보이는 에러”📤 Provisioning Logpush (R2 + Job)...+ chmod +x /home/runner/work/newsfork-seeds/newsfork-seeds/.github/scripts/steps/provision-logpush.sh+ /home/runner/work/.../provision-logpush.sh...+ [[ -n '' ]]++ eval 'echo ${LOGPUSH_R2_ACCESS_KEY_ID_STAGING:-}'+++ echo+ [[ -n '' ]]+ echo '::error::Logpush R2 Access Key ID not set. Set LOGPUSH_R2_ACCESS_KEY_ID or LOGPUSH_R2_ACCESS_KEY_ID_STAGING'##[error]Logpush R2 Access Key ID not set. Set LOGPUSH_R2_ACCESS_KEY_ID or LOGPUSH_R2_ACCESS_KEY_ID_STAGING+ exit 1##[error]Logpush provisioning failed##[error]Process completed with exit code 1.- STEPS_DIR 수정은 정상 동작:
provision-logpush.sh가 steps 경로에서 실행되고 있음. - 실패 지점:
provision-logpush.sh내부에서 R2 자격증명 확인 시, 값이 비어 있어exit 1로 종료.
2. 문제점 정리
섹션 제목: “2. 문제점 정리”2.1 직접 원인
섹션 제목: “2.1 직접 원인”- GitHub Secrets에 Logpush용 R2 자격증명이 없음.
LOGPUSH_R2_ACCESS_KEY_ID또는LOGPUSH_R2_ACCESS_KEY_ID_STAGING미설정LOGPUSH_R2_SECRET_ACCESS_KEY또는LOGPUSH_R2_SECRET_ACCESS_KEY_STAGING미설정
provision-logpush.sh는 staging/production일 때 R2 시크릿이 없으면 반드시 실패(exit 1) 하도록 되어 있음.provision-resources.sh는 Logpush 단계 실패 시 전체 provision을 실패로 처리함.
그래서 시크릿을 추가하기 전에는 staging/production 배포 시 provision job 전체가 실패함.
2.2 설계와의 관계
섹션 제목: “2.2 설계와의 관계”- 기획서(LOGPUSH_INTEGRATION_PLAN.md)에서는 staging/production에 Logpush를 권장/필수로 두고, 시크릿은 GitHub Secrets로 두도록 했음.
- 현재 구현은 “시크릿 없음 = 즉시 실패”로 되어 있어, 시크릿을 아직 넣지 않은 저장소에서는 배포가 막힘.
3. 해결 방향 (두 가지)
섹션 제목: “3. 해결 방향 (두 가지)”방안 A: 시크릿 필수 유지 + 문서화
섹션 제목: “방안 A: 시크릿 필수 유지 + 문서화”- 내용: 동작은 그대로 두고, “staging/production 배포 전에 반드시 Logpush R2 시크릿을 설정해야 한다”고 문서화.
- 장점: Logpush가 켜진 환경에서는 항상 로그 수집이 보장됨.
- 단점: 시크릿을 설정할 때까지 전체 배포가 불가하며, Logpush를 쓰지 않을 계획인 팀/브랜치도 시크릿을 넣어야 함.
방안 B: 시크릿 없으면 Logpush 생략 (권장)
섹션 제목: “방안 B: 시크릿 없으면 Logpush 생략 (권장)”- 내용: R2 시크릿이 없을 때는 Logpush provisioning/verification을 건너뛰고 계속 진행(경고만 출력). 시크릿이 있을 때만 Logpush를 설정·검사.
- 장점:
- 시크릿 없이도 기존처럼 D1/KV/Queues 배포 가능.
- 나중에 시크릿만 추가하면 다음 배포부터 Logpush가 자동으로 켜짐.
- 단점: 시크릿을 안 넣은 채로 두면 해당 환경에는 Worker 로그가 R2로 쌓이지 않음(의도된 선택).
4. 권장안: 방안 B 적용 시 변경 계획
섹션 제목: “4. 권장안: 방안 B 적용 시 변경 계획”4.1 provision-logpush.sh
섹션 제목: “4.1 provision-logpush.sh”- 현재: R2 Access Key ID / Secret 중 하나라도 없으면
::error::출력 후 exit 1. - 변경:
- 공통 또는 환경별 R2 시크릿이 둘 다 없으면
- “Logpush R2 credentials not set; skipping Logpush provisioning” 같은 warning만 출력하고 exit 0.
- 둘 다 있으면 기존처럼 R2 버킷 확인·생성 및 Logpush Job 생성(이미 있으면 스킵).
- 공통 또는 환경별 R2 시크릿이 둘 다 없으면
4.2 provision-resources.sh
섹션 제목: “4.2 provision-resources.sh”- 현재:
provision-logpush.sh가 비정상 종료(exit 1)하면 “Logpush provisioning failed” 후 exit 1. - 변경:
provision-logpush.sh가 exit 0으로만 끝나도록 위 4.1을 만족하면, 수정 없이도 provision은 성공으로 유지.- (4.1에서 시크릿 없을 때 exit 0으로 바꾸면 그대로 반영됨.)
4.3 verify-resources.sh
섹션 제목: “4.3 verify-resources.sh”- 현재: staging/production이면 항상 Logpush Job 존재·enabled 검사하고, 없거나 비활성이면 exit 1.
- 변경:
- staging/production이어도 Logpush용 R2 시크릿이 설정되지 않았으면
- “Logpush credentials not set; skipping Logpush verification” 같은 메시지 출력 후
- Logpush 검사 생략(exit 0 유지).
- R2 시크릿이 있을 때만 기존처럼 Logpush Job 존재·enabled 검사하고, 없거나 비활성이면 exit 1.
- staging/production이어도 Logpush용 R2 시크릿이 설정되지 않았으면
이렇게 하면:
- 시크릿 없음: provision에서 Logpush 스킵(warning), verify에서도 Logpush 스킵 → 배포 성공.
- 시크릿 있음: provision에서 Logpush 설정, verify에서 Logpush 검사 → 기존과 동일.
4.4 문서·규칙
섹션 제목: “4.4 문서·규칙”- README / LOGPUSH_INTEGRATION_PLAN.md:
- “Logpush는 R2 시크릿이 설정된 경우에만 provisioning/verification이 수행되며, 시크릿이 없으면 해당 단계는 건너뛰고 배포는 계속된다”고 명시.
- .cursor/rules/infrastructure/cloudflare-logpush.mdc:
- “시크릿 없음 시 Logpush 단계는 스킵(경고만)” 정책을 한 줄 정도 반영.
5. 요약
섹션 제목: “5. 요약”| 항목 | 내용 |
|---|---|
| 증상 | Provision job이 “Logpush R2 Access Key ID not set” 에러로 실패. |
| 직접 원인 | GitHub Secrets에 LOGPUSH_R2_ACCESS_KEY_ID(또는 _STAGING/_PRODUCTION) 및 Secret 미설정. |
| 구조적 원인 | R2 시크릿이 없을 때도 Logpush 단계를 필수로 두어, 전체 provision이 실패하도록 설계됨. |
| 권장 해결 | 방안 B: 시크릿 없으면 Logpush provisioning/verification을 스킵(경고만), 시크릿 있으면 기존처럼 수행. |
| 수정 대상 | provision-logpush.sh(시크릿 없을 때 exit 0 + 경고), verify-resources.sh(시크릿 없을 때 Logpush 검사 생략), 관련 문서/규칙. |
이 문서는 분석 및 기획만 담고 있으며, 실제 코드 변경은 별도 작업에서 진행한다.