핵심 결론: CI 파이프라인이 통과했다는 것은 자동화된 검사가 성공했다는 뜻일 뿐이며, App Store 풀 리퀘스트가 승인되었다는 의미는 아닙니다. CasaOS/ZimaOS 앱 제출이 몇 달 동안 열려 있다면 같은 배지만 계속 다시 확인하지 말고, 아직 어느 단계가 보류 중인지 파악하세요. 리포지토리 유효성 검사, 검토자 피드백, 병합 요구 사항 또는 메인테이너 검토 중 하나일 수 있습니다.
이 페이지의 실제 사례는 이례적으로 잘 준비되어 있었습니다. 앱은 v2 형식으로 마이그레이션되었고, 검사는 통과했으며, Docker 태그는 고정되어 있었고, 메타데이터도 입력되어 있었습니다. 또한 기여자는 다음과 같은 간단한 질문을 하고 있었습니다. “병합을 막고 있는 요소가 있나요? 아니면 제가 변경해야 할 사항이 있나요?”
먼저 현재 App Store 리포지토리에서 실제로 중요한 검사를 확인하세요.
현재 App Store 기여 절차에서는 기여자가 리포지토리를 포크하고 변경 사항을 적용 및 테스트한 다음, 무엇이 변경되었고 어떻게 검증했는지 설명하는 풀 리퀘스트를 열도록 요청합니다.
로컬 유효성 검사를 위해 리포지토리에서는 기여자에게 다음을 실행하도록 명시적으로 요청합니다.
./scripts/build_dist.sh정상적인 결과는 “내 Compose 파일은 문제없어 보인다”보다 더 구체적입니다. 빌드가 오류 없이 완료되고 다음을 생성해야 합니다. dist/index.json, 그리고 변경된 앱을 다음 경로에 생성해야 합니다. dist/apps/<app-id>/.
리포지토리의 App Store CI 검사는 풀 리퀘스트에서 Compose 유효성 검사와 전체 v2 빌드 검사를 실행합니다. 잘못된 YAML, 필수 앱 메타데이터 누락, 참조된 에셋 누락 또는 아키텍처 불일치로 인해 빌드가 실패할 수 있습니다.
CI가 통과하는 것은 필수지만, 그것이 병합 결정은 아닙니다.
많은 기여자가 놓치는 부분입니다. 자동화된 검사가 성공했다는 것은 해당 검사가 테스트한 조건을 커밋이 충족했다는 뜻일 뿐입니다. GitHub 상태 검사는 검토 및 병합 결정과 별개입니다.
풀 리퀘스트가 계속 열려 있는 이유는 다음이 필요하기 때문입니다.
- 메인테이너 또는 코드 소유자의 검토
- 요청된 변경 사항 반영
- 최신 상태로 업데이트해야 할 브랜치
- 해결해야 할 병합 충돌
- CI로는 결정할 수 없는 저장소별 승인 또는 큐레이션 결정.
GitHub 병합 요구 사항에서는 검토, 상태 확인 및 브랜치 규칙을 별도의 병합 조건으로 취급합니다.
PR 자체를 사용하여 차단 요소를 파악하세요
또 다른 “업데이트가 있나요?” 댓글을 게시하기 전에 네 곳을 확인하세요.
- 확인 항목: 오래된 SHA가 아니라 최신 커밋이 필수 워크플로를 통과했는지 확인하세요.
- 대화: 해결되지 않은 유지 관리자의 댓글이나 변경 요청을 확인하세요.
- 변경된 파일: v2 마이그레이션으로 인해 레거시 메타데이터가 잘못된 위치에 남아 있지 않은지 확인하세요.
- 병합 상자: GitHub는 일반적으로 검토, 상태 확인, 충돌 해결 또는 브랜치 업데이트가 아직 필요한지 알려 줍니다.
CI가 정상이고 병합 상자에 기여자가 수정할 수 있는 차단 요소가 표시되지 않는다면, 남은 단계는 또 다른 코드 변경이 아니라 인적 검토일 가능성이 큽니다.
v2 제출에서는 Docker 컨테이너뿐 아니라 소스 계약을 검증하세요
작동하는 컨테이너라고 해서 자동으로 유효한 App Store 항목이 되는 것은 아닙니다. 현재 v2 프로토콜에서는 소스 앱 정의에 표준 Docker Compose 런타임 구성과 최상위 x-casaos 메타데이터 블록이 포함되어야 합니다. x-casaos 메타데이터 스키마는 id, main, index, port_map, icon, title, 카테고리, 아키텍처 및 버전 메타데이터와 같은 필드를 정의합니다.
따라서 제출 내용에 “CI 통과”라고 적혀 있을 때 유용한 후속 질문은 “SonarQube도 통과했나요?”가 아니라 다음과 같습니다.
- 다음은
./scripts/build_dist.sh최신 브랜치에서 통과했나요? - 앱이 예상된 v2 출력을 생성하나요?
- 참조된 모든 아이콘, 썸네일, 스크린샷에 접근할 수 있나요?
- 선언된 아키텍처가 이미지와 일치하나요?
- 버전 및 릴리스 메타데이터가 최신 상태인가요?
- 모든 검토 댓글을 해결했나요?
노이즈를 만들지 않고 후속 확인하는 방법
제출된 지 오랫동안 조용했다면 원래 제안 내용을 전부 반복하는 대신 간결한 상태 업데이트를 한 번 게시하세요. 유용한 후속 메시지는 다음과 같습니다.
PR: #888
최신 커밋: <SHA>
v2 빌드: ./scripts/build_dist.sh 통과
GitHub Actions: 최신 커밋에서 통과
열린 리뷰 댓글: 없음
필요한 것: 메인테이너 측에 남아 있는 차단 요소가 있는지 확인그러면 메인테이너가 즉시 답변할 수 있는 질문이 됩니다.
공식 스토어 리뷰가 느리다면 타사 스토어는 유효한 배포 경로입니다
v2 생태계는 하나의 저장소에만 국한되지 않습니다. ZimaOS는 호환 가능한 저장소를 위한 타사 스토어 설정도 문서화하고 있습니다. 공식 머지 전에 커뮤니티 배포가 필요한 앱이라면, 원래 PR이 열린 상태에서 관리되는 타사 스토어를 통해 게시하는 것이 실용적인 대안이 될 수 있습니다.
기여자가 아닌 사용자를 위해 ZimaOS App Store는 원클릭 앱 모델과 타사 스토어 개념을 설명합니다. ZimaOS 앱 플랫폼에서는 현재 생태계 개요를 제공합니다. Docker 중심 앱 테스트를 위한 소형 호스트를 구축한다면 ZimaBoard 2는 관련 x86 테스트 플랫폼이지만, 앱 제출에 필요한 것은 아닙니다.
FAQ
CI를 통과하면 내 앱이 이미 머지되어야 한다는 뜻인가요?
아니요. CI는 자동화된 워크플로에서 검증하는 내용만 입증합니다. 사람의 리뷰, 저장소 규칙, 미해결 댓글, 충돌 및 메인테이너의 결정은 별개입니다.
현재 App Store에서 가장 유용한 로컬 검증 명령은 무엇인가요?
저장소의 기여 가이드는 다음을 안내합니다 ./scripts/build_dist.sh. 정상적으로 완료되고 예상되는 v2 파일이 생성되는지 확인하세요.
모든 검사가 통과했다면 코드를 계속 변경해야 하나요?
특별한 이유가 없다면 안 됩니다. 먼저 머지 상자와 리뷰 댓글을 확인하세요. 기여자가 수정할 수 있는 차단 요소가 없다면 추측성 변경을 하기보다 남은 리뷰 결정을 요청하세요.
공식 스토어 외부에 앱을 게시할 수 있나요?
예. 현재 v2 문서는 타사 ZimaOS 호환 스토어를 명시적으로 지원하므로, 외부 스토어는 정당한 배포 경로가 될 수 있습니다.
