Key conclusion: a green CI pipeline proves that the automated checks passed; it does not mean an App Store pull request has been approved. If a CasaOS/ZimaOS app submission has been open for months, stop rechecking the same badges and determine which layer is still pending: repository validation, reviewer feedback, merge requirements, or maintainer review.
重要な結論：CIパイプラインがグリーンであることは、自動チェックに合格したことを証明するだけです。App Storeのプルリクエストが承認されたことを意味するわけではありません。CasaOS/ZimaOSアプリの申請が何か月もオープンのままなら、同じバッジを再確認するのはやめて、どの層がまだ保留中なのかを確認してください。リポジトリの検証、レビュアーからのフィードバック、マージ要件、またはメンテナーによるレビューのいずれかです。
このページの背景となった実例は、非常によく準備されていました。アプリはv2形式へ移行済みで、チェックはグリーン、Dockerタグは固定され、メタデータも入力済みでした。そしてコントリビューターが尋ねていたのは、次のシンプルな質問でした。—「マージを妨げているものや、私の側で必要な変更はありますか？」
まず、現在のApp Storeリポジトリで実際に重要なチェックを確認してください
現在のApp Storeへのコントリビューションフローでは、リポジトリをフォークし、変更を加えてテストしたうえで、何を変更し、どのように検証したかを説明するプルリクエストを作成するようコントリビューターに求めています。
./scripts/build_dist.shローカル検証では、リポジトリはコントリビューターに次の実行を具体的に求めています。 正常な結果は、「Composeファイルに問題がなさそう」という状態よりも具体的です。ビルドはエラーなく完了し、次を生成する必要があります。また、変更したアプリを次の場所に生成します。 dist/apps/<app-id>/.
リポジトリのApp Store CIチェックは、プルリクエストに対してComposeの検証とv2の完全なビルドチェックを実行します。無効なYAML、必須のアプリメタデータの欠落、参照先アセットの欠落、またはアーキテクチャの不一致があると、ビルドに失敗する可能性があります。
CIがグリーンであることは必要ですが、それだけでマージが決まるわけではありません
多くのコントリビューターが見落とす点です。自動チェックに合格しても、そのチェックでテストされた条件をコミットが満たしたことが報告されるだけです。GitHubのステータスチェックは、レビューやマージの判断とは別のものです。
プルリクエストが引き続きオープンのままになる理由は、次のいずれかが必要だからです。
- メンテナーまたはコード所有者によるレビュー
- 対応すべき変更要求
- 最新の状態に更新すべきブランチ
- 解決すべきマージコンフリクト
- CIでは判断できない、リポジトリ固有の受け入れ基準やキュレーション上の判断。
GitHubのマージ要件では、レビュー、ステータスチェック、ブランチルールが別々のマージ条件として扱われます。
PR自体を使ってブロッカーを特定する
もう一度「何か進展はありますか？」というコメントを投稿する前に、次の4か所を確認してください:
- チェック: 古いSHAではなく、最新のコミットが必要なワークフローに合格していることを確認してください。
- 会話: 未解決のメンテナーコメントや変更依頼を探してください。
- 変更されたファイル: v2への移行によって、古いメタデータが誤った場所に残っていないことを確認してください。
- マージボックス: GitHubは通常、レビュー、ステータスチェック、競合解決、ブランチ更新のいずれがまだ必要かを知らせます。
CIが成功し、マージボックスに投稿者が修正できるブロッカーが表示されていない場合、残っている作業は別のコード変更ではなく、人によるレビューである可能性が高いです。
v2投稿では、Dockerコンテナだけでなく、ソースの契約を検証してください
動作するコンテナだからといって、自動的に有効なApp Storeエントリになるわけではありません。現在のv2プロトコルでは、ソースアプリ定義に標準的なDocker Composeランタイム設定と、トップレベルの x-casaos メタデータブロックの両方が含まれている必要があります。x-casaosメタデータスキーマでは、id、main、index、port_map、icon、title、カテゴリ、アーキテクチャ、バージョンメタデータなどのフィールドが定義されています。
そのため、投稿に「CI passed」と書かれている場合、役に立つフォローアップは「SonarQubeは通りましたか？」ではなく、次のようなものです:
- そうですか
./scripts/build_dist.sh最新のブランチでパスしますか？ - アプリは想定されるv2出力を生成しますか？
- 参照されているすべてのアイコン、サムネイル、スクリーンショットにアクセスできますか？
- 宣言されたアーキテクチャはイメージと一致していますか？
- バージョンとリリースのメタデータは最新ですか？
- すべてのレビューコメントに対応済みですか？
ノイズを生じさせずにフォローアップする方法
投稿が長期間静かなままの場合は、元の提案文全体を繰り返すのではなく、簡潔な状況更新を1件投稿してください。役に立つフォローアップは次のようになります:
PR: #888
最新のコミット: <SHA>
v2ビルド：./scripts/build_dist.sh に合格
GitHub Actions：最新コミットでグリーン
オープンなレビューコメント：なし
必要なもの：メンテナー側に残っているブロッカーの確認これにより、メンテナーはすぐに回答できる質問を受け取れます。
公式ストアのレビューに時間がかかる場合、サードパーティストアは有効な配布経路です
v2エコシステムは1つのリポジトリに限定されません。ZimaOSでは、互換性のあるリポジトリ向けにサードパーティストアの設定も案内しています。公式マージ前にアプリをコミュニティへ配布する必要がある場合、元のPRをオープンのまま、メンテナンスされているサードパーティストアを通じて公開することが実用的な代替策になります。
ユーザー向けのZimaOS App Storeでは、ワンクリックアプリモデルとサードパーティストアの概念を説明しています。ZimaOSアプリプラットフォームでは、現在のエコシステムの概要を確認できます。Dockerを多用するアプリのテスト用に小型ホストを構築する場合、ZimaBoard 2は関連するx86テストプラットフォームですが、アプリの申請に必須ではありません。
FAQ
CIに合格すれば、アプリはすでにマージされるべきですか？
いいえ。CIで確認できるのは、自動化されたワークフローが検証する内容だけです。人によるレビュー、リポジトリのルール、未解決のコメント、競合、メンテナーの判断は別のものです。
現在のApp Storeで最も役立つローカル検証コマンドは何ですか？
リポジトリのコントリビューションガイドには、次のリンクがあります ./scripts/build_dist.sh. 正常に完了し、想定されるv2ファイルが生成されることを確認してください。
すべてのチェックがグリーンでも、コードを変更し続けるべきですか？
特別な理由がない限り、やめておきましょう。まずマージボックスとレビューコメントを確認してください。コントリビューターが修正できるブロッカーがない場合は、推測に基づく変更を行うのではなく、残りのレビュー判断を求めてください。
公式ストア以外でアプリを公開できますか？
はい。現在のv2ドキュメントでは、サードパーティ製のZimaOS互換ストアが明示的にサポートされているため、外部ストアは正当な配布経路になり得ます。
