ci: managed-device selected 레인이 같은 클래스 selector 를 앞 2개만 실행 — 선언·검증 정책과 실행이 불일치 #1378

작업 유형

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

주 담당 모듈

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

개요

📜 Overview (Required)

#1333(PR #1349)로 도입된 managed-device selected 레인이 같은 클래스의 selector 를 선언 순서 앞 2개만 실행한다. 정책(ci-test-plan.mjs)은 변경한 androidTest 파일의 @test 전량 선언을 강제하고, 검증기(verify-android-test-plan-result.mjs)는 선언 전량이 결과 XML 에 있기를 요구하므로 — @test 3개 이상인 테스트 파일을 건드린 PR 은 selected 레인을 구조적으로 통과할 수 없다. 실행부만 선언을 못 따라가는 상태다.

실측 (2026-08-28, 독립 3개 런)

• Gradle 호출은 -Pandroid.testInstrumentationRunnerArguments.class=<selector 콤마 목록> 단일 인자, 단일 invocation (아티팩트 _temp/android-test-logs/api30.log 로 확인 — 재시도 없음).
• ANDROID_TEST_OUTCOME=success — 실행 자체는 조용히 성공하므로 utp 발견 단계에서 이미 잘린다.
• 메서드별 어노테이션 차이 없음(전부 평범한 @Test).

경계 추정

클래스별 개수 상한 2 는 ADV=3 전부 실행과 모순. 길이로 보면 클래스별 그룹 문자열(클래스#m1,m2,…) 기준 APP 2개=207자(실행) / 3개=297자(잘림), ADV 3개=277자(실행) — 클래스별 ~280자 부근 상한과 정합. 정확한 경계는 AGP/utp 필터 파싱 소스 확인이나 계측 실험으로 특정 필요.

처방 (안)

android-managed-device.yml 의 단일 gradle invocation 을 청크 분할 실행으로:

• 같은 클래스의 selector 는 invocation 당 최대 2개(개수·길이 두 가설 모두에서 안전), 다른 클래스의 청크는 한 invocation 에 동승 가능(refactor(receiver): 수신자 열람 흐름 리소스 89건을 receiver presentation 소유로 이동 (#1066) #1373 이 방증).
• invocation 수 = max(클래스별 ceil(메서드 수/2)) ≤ 10 (plan 상한 20개).
• 청크별 결과 XML 을 별도 디렉터리에 보존해 합친 뒤 기존 verify·render 에 전달.
• full 모드(FULL_SELECTOR 단일 selector)는 무영향.

수정 전 .github/scripts/*-policy.test.mjs·ci-test-plan.test.mjs 대조(정책 테스트가 결정을 고정하고 있음).

영향

• PR fix(receiver): 수신자 본인 확인 캐시를 발신자별 키로 격리 (#597) #1371, refactor(receiver): 수신자 열람 흐름 리소스 89건을 receiver presentation 소유로 이동 (#1066) #1373 이 이 결함만으로 API 30 레인 red (선언·실행된 테스트는 전부 통과).
• 머지 후 두 PR 재트리거로 E2E 검증 가능.

📍 Note (Optional)

• 근본 원인(AGP utp 의 class 필터 파싱 어디서 잘리는지)을 특정하면 청크 상한을 정확 경계로 완화할 수 있다 — 후속 재량.