maintenance(ci): 스크린샷 골든 커밋 뒤 필수 검증을 다시 붙이는 workflow_dispatch 브리지가 성공 0건 #1850

작업 유형

maintenance — CI·빌드·의존성·저장소 운영 유지보수

주 담당 모듈

platform — Android 앱·CI·빌드·릴리스·저장소 운영

개요

screenshot-baseline-apply.yml 이 골든을 커밋한 뒤 필수 검증을 다시 붙이려고 쏘는 workflow_dispatch 브리지가 한 번도 성공한 적이 없다. 그래서 골든이 바뀌는 PR 마다 사람이 대기 중인 run 을 손으로 승인해야 한다.

왜 브리지가 필요한가 — GITHUB_TOKEN 으로 PR 브랜치에 baseline 커밋을 올리면 pull_request 이벤트가 다시 발생하지 않는다(Actions 재귀 방지). 그래서 새 SHA 에는 required check 가 안 붙는다. pr-validation.yml 의 workflow_dispatch 트리거가 그 구멍을 메우기로 돼 있고, 워크플로 주석도 그렇게 적고 있다.

.github/workflows/pr-validation.yml:23-25

# GITHUB_TOKEN 으로 PR 브랜치에 baseline/stack merge commit 을 올리면 pull_request
# 이벤트가 다시 발생하지 않는다. 권한 있는 bridge 가 같은 SHA 에 필수 검증을 붙일 때 쓴다.

실측 (2026-09-03)

pr-validation.yml 의 workflow_dispatch run 을 최근 60건까지 훑었다. 성공이 0건이다.

실패 run 은 전부 job 0개다.

$ gh api repos/Afternote/Afternote-FE/actions/runs/33743110951 -q '{status,conclusion,path}'
{"status":"completed","conclusion":"failure","path":".github/workflows/pr-validation.yml"}
$ gh run view 33743110951 --json jobs --jq '.jobs|length'
0

즉 워크플로가 시작 자체를 못 한다(startup failure). job 이 없으니 로그도 check-run annotation 도 남지 않아 gh 로는 사유를 읽을 수 없다 — check-suites/<id>/check-runs 도 0건이다.

실행 주체는 브리지가 맞다. 위 실패 33건의 actor 는 github-actions[bot] 이고 head 브랜치는 골든이 바뀐 PR 브랜치들이다(fix/1779-…, fix/1781-…, refactor/1672-…, fix/1815-…, fix/1798-…, fix/793-…, feat/457-… 등 8/27 이후 전 기간에 걸쳐 있다).

영향

골든이 바뀌는 PR 마다 required check 가 새 SHA 에 안 붙어 action_required 로 멈춘다. 2026-09-03 에 #1840 은 대기 중이던 run 6개를 사람이 승인해서야 초록을 받았다. 자동화가 있다고 믿고 기다리면 PR 이 조용히 멈춰 있는다.

이미 배제한 원인

• 입력 타입 불일치 아님 — pr-validation.yml 의 pull_request_number 는 type: number 로 선언돼 있고, 이를 받는 reusable 4종(repository-quality·lint·unit-test·screenshot)도 전부 type: number 다.
• 입력 누락 아님 — 호출부(screenshot-baseline-apply.yml:238-242)가 넘기는 TARGET_PR 은 앞선 id: target 스텝이 Number.isSafeInteger 와 PR 조회로 검증한 값이다.

완료 조건

• startup failure 의 실제 사유를 특정한다. job 0개라 gh 로는 안 보이니 Actions UI 의 run 페이지 또는 GITHUB_TOKEN 으로 만든 workflow_dispatch 의 제약을 근거로 확인한다.
• 브리지가 실제로 초록을 받는 것을 성공 run 1건으로 실측한다. 「고쳤다」의 근거를 코드 변경이 아니라 성공 run 으로 삼는다.
• 고칠 수 없는 제약이면(예: GITHUB_TOKEN 으로는 원천적으로 불가) 브리지를 걷고 대안을 세운다 — PAT·App 토큰으로 커밋해 pull_request 이벤트를 정상 발생시키는 쪽이 후보다. 죽은 브리지를 남겨 두면 「자동으로 붙는다」는 잘못된 전제가 계속 유지된다.
• 같은 호출부가 함께 쏘는 codeql.yml·merge-order-guard.yml dispatch 도 같은 상태인지 확인하고 함께 처리한다.

자식 이슈

없음

참고

• 발견 경위: refactor(core): 테스트가 직접 접근하는 file-local helper의 visibility를 private로 축소 #1672(PR refactor(core): 테스트만 쓰던 core 선언 18개를 private 로 줄인다 (#1672) #1840) 작업 중 골든 재생성이 Apply Screenshot Baselines 이후 멈춰 있는 것을 보고 전수 조회했다.
• 호출부: .github/workflows/screenshot-baseline-apply.yml 의 Dispatch required checks on the resulting SHA 스텝.
• 관련(다른 결함, 모두 CLOSED): fix(ci): screenshot baseline Apply의 PR 댓글 권한 403 복구 #1323 baseline Apply 의 PR 댓글 권한 403 · fix(ci): screenshot-baseline 라벨이 붙은 PR의 중복 실패 안내 댓글 생략 #1298 중복 실패 안내 댓글 · fix(ci): screenshot baseline 생성이 xfail 목록을 안 봐 core:ui 변경 PR 의 골든 갱신이 통째로 막힌다 #1448 baseline 생성이 xfail 목록 미참조.