Barbelic devdocs

Appearance

HQ 수동 랜딩 승인 제거 — 담당자가 요청하고 Actions가 머지·스테이징을 진행 ​

관련 이슈: #1313. v0.18.0 총괄의 운영 결정 D8이며, 62개 개선 작업과 Phase 1의 단계 순서는 바꾸지 않는다.

문제 ​

G01에서 도입한 landing:active는 HQ 세션만 부여할 수 있었다. 실제 검사는 라벨 수만 세었고 HQ 부재·세션 종료에 따른 자동 인계가 없어, 검증을 마친 마이그레이션 PR도 사람이 돌아오기를 기다렸다. PC 내부 잠금은 다른 PC의 동시 랜딩을 막지 못했다.

변경 ​

담당자가 기존 로컬 검증과 원격 CI를 마친 다음 한 번 요청한다.

bash
npm run landing:request -- --pr <N>

CLI는 clean worktree와 PR head 일치를 확인한다. 새 마이그레이션이면 기존 preflight 기록의 브랜치·파일 해시·24시간 유효성과 최신 main 기준 번호도 검사한다. 이후 요청은 GitHub Actions에서 계속되므로 담당자나 HQ 세션의 상주가 필요 없다.

Landing queue의 저장소 공통 concurrency 그룹이 머지부터 staging 확인까지 직렬 실행한다. queue: max로 대기 요청을 보관하고 실행 중 요청을 취소하지 않는다. 별도 서버·DB 잠금·PAT·GitHub App·새 secret은 추가하지 않는다.

실행 시점에 같은 저장소의 main 대상 PR, 요청한 head, 최신 main 포함 여부, 실제 Repository checks 성공을 확인한다. 마이그레이션 PR은 DB 검증 잡도 실제 성공해야 한다. 대기 후 head·main·호환 판정을 다시 읽고 해당 head를 squash merge한다. admin-hold와 관리자+마이그레이션의 호환 근거는 유지하며 담당자가 판정한다.

GITHUB_TOKEN으로 머지한 이벤트는 push workflow를 자동 유발하지 않으므로 기존 Deploy를 staging 대상으로 명시 호출한다. database → functions → frontend → smoke 작업과 실제 CRUD 실행 성공을 확인한다. Deploy 큐에 늦게 진입한 낡은 main 스냅샷은 배포 전에 건너뛴다. 실패한 작업만 재실행하면 최초 resolve 단계가 반복되지 않으므로, DB·함수·프론트엔드 작업도 최신 SHA를 각각 확인해 오래된 배포 재시도를 거부한다.

실패와 재개 ​

  • head/main 변경: 최신화·번호 확인·검증 후 다시 요청한다. 큐가 PR 코드를 고치거나 rebase하지 않는다.
  • 실패·취소·시간 초과: Actions가 슬롯을 반납한다. 남은 라벨을 HQ가 회수할 필요가 없다.
  • 이미 머지된 PR: 같은 명령으로 staging 상태를 확인하고 필요한 배포만 재개한다. 머지를 중복 수행하지 않는다.
  • 현재 main의 staging 실패: 무관한 PR은 멈춘다. 실패를 수리하는 PR은 --repair-staging-run <실제 실패 run ID>로 근거를 명시한다.
  • 배포 요청 수신 후 실행이 보이지 않으면 중복 요청을 반복하지 않고 실행 목록 확인을 안내한다.

--dry-run은 머지·배포 없이 준비 상태만 확인한다. 자동화 자체를 시험할 때만 --workflow-ref <branch>와 함께 사용할 수 있다. 실제 랜딩은 main의 Actions dispatch에서만 실행한다.

보장 범위와 검증 ​

자동 큐로 요청한 랜딩 사이의 직렬화를 보장한다. 웹 수동 머지나 별도 직접 배포를 물리적으로 잠그는 저장소 권한 변경은 하지 않았으므로, 큐 대상 작업은 표준 명령을 사용한다. Production 릴리스와 파괴적 데이터 변경의 오너 승인 조건은 유지한다.

tests/react/selfServiceLanding.test.mjs는 고정 시계와 GitHub 응답 fixture로 라벨 없는 정상 랜딩, exact-head 머지, CI/DB 검증 누락, head/main 변경, 관리자 호환, 배포 생략, 실패 배포 수리, 늦은 실행 발견, 불확실한 머지 응답 뒤 재개, 시간 상한을 검증한다. 실제 CI·Actions 실행 증거는 PR과 이슈에 남긴다.

현행 절차: 마이그레이션 랜딩, HQ 운영 정본, 전체 로드맵.

GitHub 동작 근거: concurrency, GITHUB_TOKEN 이벤트 제한.