무료 플랜에서 24시간 동안 배포 146회, 배포를 GitHub Actions로 옮겼습니다

AI 요약

ResuHive와 사이드 프로젝트 두 개가 한 저장소에 있고, 세 프로젝트 모두 Vercel의 Git 연동으로 배포됐습니다. 무료 플랜은 24시간 동안 배포 100회를 허용하지만, 각 프로젝트가 모든 커밋에서 빌드됐습니다. 브랜치 푸시 때 미리보기 배포가 생기고 병합 뒤에는 프로덕션 빌드가 돌아, 변경 하나에 배포가 약 6회씩 발생했습니다. 경로를 기준으로 빌드를 건너뛰는 규칙도 취소된 빌드의 횟수까지 되돌리지는 않았습니다. 24시간 동안 배포 146회 중 55회는 생성 직후 취소됐고, 한도 초과로 병합된 수정이 사이트에 반영되지 않은 날도 네 차례 이상 있었습니다.

GitHub Actions로 배포 통합

운영자는 Vercel의 Git 배포를 끄고 GitHub Actions 워크플로 하나에서 배포를 처리하도록 바꿨습니다. 병합한 변경이 들어간 폴더에 해당하는 프로젝트만 배포합니다. 문서만 수정하면 배포가 없고, 일반적인 변경은 한 번 배포합니다. 브랜치 푸시로는 빌드하지 않으며, 노트북에서 수동 배포하던 사이드 프로젝트도 같은 흐름에 포함했습니다. Vercel이 요청을 제한하면 시간 단위 작업이 막힌 프로젝트를 다시 시도합니다.

오류 처리 수정

배포 단계가 첫 오류에서 셸을 종료하도록 설정돼 있어 실패 원인을 확인하기 전에 스크립트가 끝났습니다. 그 결과 요청 제한도 빌드 실패로 보고됐습니다. 이 동작을 고친 뒤에도 요청 제한은 작업 실패로 표시됐고, 그대로 두면 재시도 때마다 실패 알림이 발송될 상황이었습니다. 운영자는 이를 막기 위해 오류 처리를 두 차례 손봤습니다.

Indie Hackers 반응

• @VeloquentLabs — 경로 필터링이 맞는 방법이고, 취소한 빌드도 100회 한도에 포함된다는 점이 많은 사람이 놓치는 부분입니다. 시간 단위 재시도 작업이 조용히 건너뛴 경우를 잡으려면 매일 밤 변경된 폴더와 실제 배포 목록을 비교하는 점검을 더할 만합니다. 첫 오류에서 종료되는 문제도 실패 처리 전에 요청 제한 메시지를 명시적으로 확인하면 막을 수 있습니다. 세 프로젝트가 배포 단계를 공유하도록 공통 워크플로 파일을 고려했나요?
• @ska1296 — 경로 필터링이 맞습니다. 문서 커밋마다 프로젝트 세 개를 다시 빌드하려고 더 비싼 요금제를 쓰는 건 아깝습니다. 시간 단위 재시도도 좋은 방법입니다. 대부분은 다음 병합을 기다렸을 겁니다.
• @Harries Steele — 취소한 빌드도 횟수에 포함된다는 점이 사람들이 놓치는 부분입니다. Vercel 프로젝트 세 개가 있는 모노레포는 아무것도 배포하기 전에 커밋 하나로 배포 여섯 회를 씁니다. 건너뛰기 규칙으로 한도를 돌려받지는 못합니다. 워크플로 하나에 경로 필터와 다음 병합을 기다리지 않는 재시도를 둔 방식이 맞습니다. 오래 잘 돌아가게 하려면 두 가지를 챙기세요. 작업 요약에 어떤 프로젝트를 왜 건너뛰었는지 적어야 합니다. 6주 뒤에는 조용히 끝난 작업이 문서 변경 때문인지 필터 패턴 오류 때문인지 기억하기 어렵습니다. 실패 원인도 나눠야 합니다. 요청 제한은 나중에 재시도하고 빌드 오류는 멈춰서 알리는 식입니다. 둘 다 빨간색으로 표시하면 알림을 꺼버릴 테고, 그러면 한도가 다시 몰래 차오를 겁니다. 막힌 프로젝트가 밤새 알림을 보내지 않도록 시간 단위 재시도 횟수도 제한하세요. 경로 필터가 한 달간 제대로 작동하는지 확인하기 전에는 상위 요금제로 바꾸지 않겠습니다. 한도 문제는 커밋이 건드리지 않은 프로젝트까지 배포한 결과였습니다.
• @kelly lynn — 자세한 설명 감사합니다. 시간 단위 재시도는 좋은 해결책이네요. 저는 Railway를 써서 아직 이런 한도에 걸리지는 않았습니다.

원문: Indie Hackers / 번역·요약: Trawling