Files

T

2026-07-25 12:53:13 +09:00

title, source_type, status, related_branches, related_projects, tags, created, status_label

title

source_type

status

related_branches

related_projects

interview-prep: ci-release-gate-fan-in-blocking

Layer: raw/interviews/ — 면접 질문 원본 수집·연구 노트. status_label: collecting

Parent / 부모

raw/branch-notes/feature-ci-quality-gates-contract — release-blocking 게이트 fan-in 을 구현하며 "한 게이트가 실패하면 정말 릴리스가 막히나?" 라는 질문이 자연스럽게 도출됨.

질문 원문: "여러 CI 게이트(빌드/테스트/정적분석/계약테스트…)를 하나의 required check 로 묶을 때, 그 중 하나라도 실패하면 머지가 반드시 막히도록 어떻게 보장했나요?"
출처: 예상 질문 (branch 작업에서 유추 — fan-in status 전파는 branch-note Claim C1 의 핵심 불확실성)
받은 날짜·맥락: (예상)

핵심 평가 대상: CI 도구의 기본 동작 을 안다고 착각하지 않고 실제로 검증하는가 + "통과처럼 보이지만 차단 안 되는" 위양성 위험 인지.
함정 / 흔히 빠지는 답변 패턴: "aggregator 잡을 만들고 needs 로 묶었다" 로 끝내는 것. needs + if: success() aggregator 는 상위 실패 시 failure 가 아니라 skipped 가 되고, branch protection 이 skipped 를 통과로 오해할 수 있다 → 차단 실패.

결론 먼저: aggregator 를 if: always() 로 두고, needs.*.result 를 스캔해 failure/cancelled 가 하나라도 있으면 명시적으로 exit 1. 그래야 "1건 실패 → release block" 이 보장된다.
근거: GitHub Actions 의 needs 기본은 상위 실패 시 하위 잡 skip. success() 는 그 기본을 적은 것일 뿐 aggregator 를 실패 로 만들지 않는다. skip 은 차단이 아니다.
검증: 의도적으로 matrix 잡 1개를 실패시켜 aggregator 가 fail 인지 skip 인지 직접 확인(공식 문서만 믿지 않음 — evidence-first).
세부: PR-only 잡(예: 라벨 게이트)은 push 이벤트에서 skipped 이므로 result 스캔에서 skip 은 OK 로 통과시키고, 비차단 잡(flaky quarantine)은 애초에 needs 에서 제외한다.
확장: 워크플로 간 needs 는 불가능 → 여러 워크플로의 required 잡 합집합 을 branch protection 에 등록해야 전체 release-blocking 집합이 완성된다.

"continue-on-error 와 if: always() 의 차이는?" → 전자는 잡을 실패해도 성공으로 보고(비차단 게이트용), 후자는 상위 결과와 무관히 실행(aggregator 용).
"matrix 잡 일부만 실패하면?" → fail-fast: false + result 스캔이면 모든 조합을 돌려 어떤 adapter 가 깨졌는지까지 본 뒤 차단.