ci: 300파일 path-filter 가드가 릴리스 PR 을 구조적으로 막는다 — develop→main 은 분리할 수 없다 #1559

작업 유형

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

주 담당 모듈

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

개요

repository-quality.yml 의 Guard server-side path filter boundary 가 변경 파일 300개를 넘는 PR 을 fail-closed 시킨다. 그런데 릴리스 PR(develop → main)은 본질적으로 이 경계를 넘는다.

::error::PR 변경 파일 1070개가 paths 안전 경계 300개를 초과했습니다. PR을 분리하세요.

「PR 을 분리하세요」 는 릴리스 PR 에 적용할 수 없는 조언이다. 릴리스는 develop 누적분을 한 번에 main 으로 넘기는 것이고, 쪼개면 그건 릴리스가 아니다.

실측 — 가드 도입 후 첫 대형 릴리스에서 드러났다

가드는 2026-08-27 8c37dd3a6(「ci: 의존성 워크플로를 변경 경로에만 실행한다」)로 들어왔다. 그 뒤 릴리스 PR 이 처음 300 을 넘은 것이 #1558 이다.

Repository Quality 는 required-checks (main) 룰셋(21653076)의 required 체크라 릴리스를 실제로 막는다.

가드의 목적에 비춰도 릴리스 PR 은 대상이 아니다

워크플로 주석이 밝힌 근거는 이것이다.

GitHub 의 server-side paths 평가는 유한한 diff 앞부분만 보므로, 그 경계를 넘는 PR 을 그대로 허용하면 뒤쪽 dependency 파일이 graph/review workflow 를 우회할 수 있다.

즉 「paths 필터를 우회한 의존성 변경이 검토 없이 들어오는 것」 을 막으려는 것이다. 릴리스 PR 은 그 위험 구조가 다르다.

• 릴리스 PR 의 모든 변경은 이미 develop base PR 로 한 번씩 들어온 것이고, 그때 각자 300 이하에서 paths 필터와 Review dependency changes 를 통과했다.
• 릴리스 PR 자체는 새 코드를 만들지 않는다 — 검증된 develop 을 main 으로 옮기는 머지다.
• 실제로 release: develop 누적 263 PR 을 main 릴리스 후보로 반영 [base: main] #1558 에서 Review dependency changes 와 Generate PR dependency graph 는 통과했다. 우회가 일어나지 않았다는 뜻이다.

제안 — 릴리스 PR 에 한해 경계를 면제한다

base == main && head == develop 인 PR 에서만 경계 초과를 통과시키고, 그 사실을 ::notice:: 로 남긴다. 다른 어떤 PR 도 면제하지 않는다.

• 「대형 PR 이면 면제」 가 아니라 「릴리스 PR 이면 면제」 여야 한다. 크기를 기준으로 열면 가드가 무의미해진다.
• 정책 테스트 supply-chain-policy.test.mjs 의 pull requests beyond the conservative path-filter boundary fail closed 도 함께 갱신한다 — 경계가 살아 있다는 단언에 릴리스 PR 예외가 릴리스 PR 에만 걸린다는 단언을 더한다.

완료 조건

• 릴리스 PR(develop → main)이 300파일을 넘어도 Repository Quality 가 통과한다
• 그 외 PR 은 종전대로 300 초과 시 실패한다
• 정책 테스트가 두 성질을 함께 잠근다
• 면제가 적용될 때 로그에 근거가 남는다

참고

• 이번 릴리스(release: develop 누적 263 PR 을 main 릴리스 후보로 반영 [base: main] #1558)는 이 가드 때문에 룰셋 임시 해제로 머지한다. 나머지 required 8종(guard·Ktlint·Android Lint·Unit Tests·Screenshots·Analyze 2종·Pixel 2 API 30 androidTest)이 통과한 상태에서 이 하나만 구조적으로 실패하는 상황이다.
• 같은 릴리스에서 드러난 다른 구멍: collect-release-scope-context.mjs 가 「main 배포는 항상 develop→main 머지에서 온다」 를 가정해 실패한다(마지막 배포 security(ci): main Actions 참조를 SHA로 고정한다 [base: main] #1273 이 feat/847 → main 직접 PR). 별건으로 뗀다.
• 관련: main 고유 커밋이 develop 으로 돌아오지 않아 릴리스 PR 이 충돌한다 — 역머지 경로 부재 #1551 (main·develop 역머지 경로 부재)