ci: ktlint 태스크 선택이 실재 여부를 안 봐 모듈 3종에서 Ktlint job 이 죽는다 — 2종 미해소 + 재발 가드 부재 #1419

작업 유형

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

주 담당 모듈

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

개요

resolve-pr-impact.mjs 가 존재하지 않는 ktlint 태스크를 선택할 수 있어, 특정 모듈의 .kt 만 바꾼 PR 은 Ktlint job 이 태스크 선택 단계에서 죽는다.

구조 — resolve-pr-impact.mjs:233-235 는 .kt 파일이 걸리면 무조건 그 모듈을 ktlintModules 에 넣고, :311-313 이 <projectPath>:ktlintCheck 로 펼친다. 그 태스크가 실재하는지는 확인하지 않는다. 전역 폴백(globalKtlintChange)이 걸린 PR 은 ktlintCheck 하나로 돌아 이 구멍을 지나친다.

실측 (develop 181875314) — 서브프로젝트 전수를 tasks.names.contains("ktlintCheck") 로 조회한 결과, src/**/*.kt 를 가지면서 ktlint 가 없는 모듈이 3개:

나머지 23개 모듈은 컨벤션 플러그인 경유로 ktlintCheck 를 갖는다. 위 3개만 plugins 블록이 컨벤션을 안 타고 직접 구성돼 있다 — :baselineprofile 은 com.android.test + baselineprofile, :feature:setting:domain 은 java-library + kotlin.jvm + kover, :konsist 는 java-library + kotlin.jvm.

언제 터지나 — PR #1279(2026-08-27, 모듈 단위 태스크 선택 도입) 이후 이 3개 모듈의 .kt 만 건드리는 PR. :konsist 건은 PR #1416 이 #1279 이후 konsist 를 건드린 첫 PR 이라 그때 드러났고(당시 gh: API rate limit exceeded 플레이크가 전역 폴백을 유발해 한 번 더 가려졌다), 나머지 2개는 아직 그런 PR 이 없어 잠복 중이다.

완료 조건

• :baselineprofile·:feature:setting:domain 에서 <모듈>:ktlintCheck 가 실재한다(적용 방식은 :konsist 선례를 따르되, 버전 없는 id(...) 여야 한다 — alias 는 "plugin already on the classpath" 로 깨진다).
• 재발 가드: resolve-pr-impact.mjs 가 태스크 부재를 조용히 넘기지 않는다. 둘 중 하나 — (a) 선택 시 실재 여부를 검사해 없으면 전역 ktlintCheck 로 폴백, (b) 정책 테스트(.github/scripts/*-policy.test.mjs)가 «.kt 보유 모듈은 전부 ktlintCheck 를 가진다» 를 단언. (b) 가 새 모듈 추가 시점에 잡아 주므로 선호.
• 위 가드가 현행 코드에 대고 먼저 실패함을 확인한 뒤 고친다.

자식 이슈

No response

참고

• 발단: PR refactor(afternote): 컴포저블 no-op 콜백 디폴트 제거 afternote 몫 + konsist 가드 (#1388) #1416(refactor(platform): 컴포저블 no-op 콜백 디폴트 — 재발 가드·컨벤션 도입 + afternote 잔여 2건 #1388 afternote 몫) 이 konsist 에 테스트를 추가하면서 Ktlint job 실패로 드러났다. 그 PR 은 :konsist 한 건만 해소했고 이 이슈가 나머지 2건과 구조 가드를 추적한다.
• 관련: perf(ci): ktlint 를 PR 당 두 번 검사 — reviewdog 경로 32초·버전 이원화 정리 #1012 «ktlint 를 PR 당 두 번 검사 — 버전 이원화 정리»(closed), ci: 삭제로 발생한 ktlint 위반을 전체 검사에서 감지 #875 «삭제로 발생한 ktlint 위반을 전체 검사에서 감지»(closed) — 둘 다 검사 범위 문제였고 이 건은 태스크 실재 여부 문제라 별개다.
• :feature:setting:domain 은 setting 담당 모듈이나 변경분이 build.gradle.kts 플러그인 한 줄이라 제품 코드가 아니다. 담당 배분은 착수 시 판단한다.
• 정책 변경 전 .github/scripts/*-policy.test.mjs 를 먼저 볼 것 — CI 결정이 거기 박혀 있어 테스트 실패는 버그가 아니라 정책 갱신 신호다.