연속된 main 변경에서 이전 Deploy가 취소됐다
Bun migration과 CI 구조를 정리하는 과정에서 main에 짧은 시간 안에 연속으로 변경이 들어갔습니다.
GitHub Actions에서는 이전 Pages Deploy가 cancelled로 끝났지만, 더 최신 commit에 대한 새로운 Deploy가 이어졌습니다.
실제 배포 흐름
| 단계 | Revision / Run | 상태 | 의미 |
|---|---|---|---|
| 1 | Commit A · 97ca593 | 새 revision | 기존 main 변경 |
| 2 | Deploy #364 | 실행 중 | Commit A 배포 시작 |
| 3 | Commit B · 76e1a3e | 새 revision | 더 최신 변경이 main에 도착 |
| 4 | Deploy #364 | Cancelled | 이전 배포가 최신 revision으로 대체됨 |
| 5 | Deploy #365 | 실행 시작 | 최신 Commit B 배포 시작 |
| 6 | Build | ✅ Success | 최신 revision 빌드 성공 |
| 7 | Pages Deploy | ✅ Success | 최신 revision이 실제 배포됨 |
핵심:
Deploy #364 cancelled는 최종 배포 실패를 의미하지 않습니다. 최신 revision인76e1a3e가Deploy #365에서 정상적으로 빌드되고 배포됐는지를 함께 확인해야 합니다.
이것은 반드시 장애를 의미하지 않는다
cancelled만 보고 배포 실패로 판단하면 안 됩니다. 이전 run과 최신 revision의 배포 결과를 하나의 흐름으로 봐야 합니다.
| 확인 항목 | 판단 기준 |
|---|---|
| 이전 run | cancelled인지 확인 |
| 최신 revision | 새로운 Deploy run이 생성됐는지 확인 |
| 최신 Build | 최신 revision의 빌드가 성공했는지 확인 |
| 최신 Deploy | 실제 Pages deployment까지 성공했는지 확인 |
이번 사례에서는 이전 run #364가 취소됐지만 최신 revision 76e1a3e에 대한 #365가 생성됐고, build를 성공적으로 완료한 뒤 Pages deployment까지 진행됐습니다.
왜 이 기록을 남기는가
CI/CD에서 중요한 것은 개별 run의 상태 하나가 아니라 revision과 deployment의 관계입니다.
| 이전 상태 | 최신 상태 |
|---|---|
97ca593 | 76e1a3e |
Deploy #364 | Deploy #365 |
| Cancelled / Superseded | Build ✅ → Deploy ✅ |
따라서 연속적인 main push가 가능한 저장소에서는 cancelled run을 즉시 장애로 분류하기보다, 최신 revision이 정상적으로 배포됐는지 확인하는 것이 더 정확합니다.
이번 Bun migration에서 이 사례까지 기록해 두면 runtime 변경뿐 아니라 실제 CI/CD 운영 과정에서 발생한 execution race와 deployment lifecycle까지 함께 설명할 수 있습니다.