GitLab on 얼쑤 · Team Edo

APK는 받을 수 있는데 QA 목록 제목은 왜 비었을까

Mon, 09 Nov 2026 00:00:00 +0900

얼쑤의 Android QA 페이지에서는 테스트할 앱 설치 파일인 APK를 고를 수 있습니다. 목록에는 파일을 만든 빌드와 연결된 변경 요청(MR)의 제목과 작성자가 함께 나옵니다. 제목이 비어 있어도 보관된 파일은 내려받을 수 있었지만, 테스터는 어떤 변경이 들어간 빌드인지 목록에서 확인하기 어려웠습니다. 11월 9일 첫 점검에서는 목록에 연결된 MR 136개 중 37개의 상세 정보가 비어 있었습니다.

설치 파일과 설명이 오는 길

Jenkins는 빌드한 APK를 보관하고 어떤 변경 요청과 연결되는지 목록에 남깁니다. 별도의 동기화 작업은 이 목록에 있는 MR 번호로 GitLab을 조회해 제목과 작성자를 채웁니다. APK는 이미 보관된 파일이어서 이 조회가 실패해도 다운로드할 수 있습니다. 빈 제목을 고치려면 APK를 다시 만드는 대신, 설명을 채우는 작업을 확인해야 했습니다.

1.4.2 종료 코드는 0, 리뷰어는 빈칸

Tue, 03 Nov 2026 14:46:20 +0900

새 PR에 리뷰어를 붙이는 규칙을 확인하던 중, gh pr edit --add-reviewer로 PR 작성자 자신에게 리뷰를 요청했을 때 종료 코드가 0으로 나왔습니다. 같은 요청을 GitHub API로 보내자 작성자에게 리뷰를 요청할 수 없다는 422 응답이 돌아왔고, PR을 다시 조회하니 리뷰어는 비어 있었습니다. 이 차이 때문에 1.4.2에서는 설정 명령이 끝난 뒤 담당자·리뷰어·라벨을 다시 읽어 반영 결과를 판단하게 했습니다. 수정 커밋

PR 생성과 메타데이터 설정 분리

coco-push, coco-merge, coco-ship이 새 PR이나 MR을 생성하면 담당자와 리뷰어의 기본 후보는 해당 요청을 연 계정입니다. 로컬 Git 커밋 작성자 대신 GitHub나 GitLab에 로그인한 계정을 조회합니다. 사용자나 저장소 지침이 다른 사람을 지정했다면 그 지시를 따릅니다. 라벨은 저장소에 이미 있는 이름과 설명을 읽어 변경에 맞는 것만 추가합니다. 이미 열려 있던 요청은 생성 시점의 자동 설정 대상에서 제외합니다.

MR 병합 뒤에도 운영 확인이 남았다

Wed, 28 Oct 2026 00:00:00 +0900

새 약관 API를 운영에서 호출해 HTTP 200을 받는 것이 한 작업의 완료 조건이었습니다. MR이 병합되자 Jira는 작업을 완료로 표시했지만, 같은 시점에 운영 API는 404를 반환했습니다.

자동 종료 대상과 운영 응답 확인

저희 프로젝트는 MR이 병합되면 연결된 작업을 완료로 전환했습니다. 약관 사례에서는 배포 이력과 운영 응답을 계속 확인해 새 버전의 200 응답까지 기록했습니다. 배포가 막힌 원인과 복구 과정은 별도 글에 정리했습니다. 인증 추가 뒤 자동 배포가 10번 실패한 이유