La relation publique de l’App Store de CasaOS ou de ZimaOS est toujours en attente

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.

Conclusion essentielle : un pipeline CI au vert prouve que les vérifications automatisées ont réussi ; cela ne signifie pas qu’une pull request de l’App Store a été approuvée. Si une soumission d’application CasaOS/ZimaOS est ouverte depuis des mois, cessez de revérifier les mêmes indicateurs et déterminez quelle couche est encore en attente : validation du dépôt, retours des évaluateurs, exigences de fusion ou examen par un responsable de maintenance.

L’exemple concret à l’origine de cette page était particulièrement bien préparé : l’application avait été migrée au format v2, les vérifications étaient au vert, les balises Docker étaient épinglées, les métadonnées étaient renseignées, et le contributeur posait une question simple : « Quelque chose bloque-t-il la fusion ou des modifications sont-elles nécessaires de mon côté ? »

Vérifiez d’abord les contrôles qui comptent réellement pour le dépôt actuel de l’App Store

Le flux actuel de contribution à l’App Store demande aux contributeurs de créer un fork du dépôt, d’effectuer et de tester les modifications, puis d’ouvrir une pull request expliquant ce qui a changé et comment cela a été validé.

./scripts/build_dist.sh

Pour la validation locale, le dépôt demande précisément aux contributeurs d’exécuter : Un résultat satisfaisant est plus précis que « mon fichier Compose semble correct ». La compilation doit se terminer sans erreur, produire, et générer l’application modifiée sous dist/apps/<app-id>/.

Les vérifications CI de l’App Store du dépôt exécutent la validation de la configuration Compose et une vérification complète de la compilation v2 sur les pull requests. Un fichier YAML invalide, des métadonnées d’application obligatoires manquantes, des ressources référencées absentes ou des incompatibilités d’architecture peuvent faire échouer la compilation.

Une CI au vert est nécessaire, mais elle ne constitue pas la décision de fusion

C’est un point que de nombreux contributeurs négligent. La réussite d’une vérification automatisée indique seulement que le commit a satisfait aux conditions testées par cette vérification. Les vérifications d’état GitHub sont distinctes des décisions d’examen et de fusion.

Une pull request peut rester ouverte parce qu’elle nécessite :

l’examen par un responsable de maintenance ou un propriétaire du code ;
les modifications demandées à traiter ;
la branche à mettre à jour ;
un conflit de fusion à résoudre ;
les décisions d’acceptation ou de curation propres au dépôt que la CI ne peut pas prendre.

Les conditions de fusion de GitHub traitent les revues, les vérifications d’état et les règles de branche comme des conditions de fusion distinctes.

Utilisez la PR elle-même pour identifier le blocage

Avant de publier un autre commentaire « une mise à jour ? », vérifiez quatre emplacements :

Vérifications : confirmez que le dernier commit, et non un ancien SHA, a réussi les workflows requis.
Conversation : recherchez les commentaires non résolus des responsables de la maintenance ou les demandes de modification.
Fichiers modifiés : vérifiez que votre migration v2 n’a pas laissé d’anciennes métadonnées au mauvais emplacement.
Boîte de fusion : GitHub vous indique généralement si une revue, une vérification d’état, une résolution de conflit ou une mise à jour de branche est encore requise.

Si la CI est au vert et que la boîte de fusion n’indique aucun blocage pouvant être corrigé par le contributeur, l’étape restante est probablement une revue humaine plutôt qu’une nouvelle modification du code.

Pour les soumissions v2, validez le contrat source, et pas uniquement le conteneur Docker

Un conteneur fonctionnel ne constitue pas automatiquement une entrée valide dans l’App Store. Le protocole v2 actuel exige que la définition de l’application source contienne une configuration d’exécution Docker Compose standard ainsi qu’un bloc de métadonnées x-casaos de niveau supérieur. Le schéma de métadonnées x-casaos définit des champs tels que id, main, index, port_map, icon, title, la catégorie, l’architecture et les métadonnées de version.

Ainsi, lorsqu’une soumission indique « CI réussie », le suivi utile n’est pas « SonarQube a-t-il réussi ? », mais plutôt :

Est-ce que ./scripts/build_dist.sh réussi sur la branche la plus récente ?
L’application génère-t-elle la sortie v2 attendue ?
Toutes les icônes, miniatures et captures d’écran référencées sont-elles accessibles ?
L’architecture déclarée correspond-elle à l’image ?
Les métadonnées de version et de publication sont-elles à jour ?
Tous les commentaires de revue ont-ils été résolus ?

Comment effectuer un suivi sans générer de bruit

Si la soumission est restée silencieuse pendant longtemps, publiez une seule mise à jour d’état concise au lieu de répéter l’argumentaire initial complet. Un suivi utile peut ressembler à ceci :

PR : #888
Dernier commit : <SHA>
Build v2 : ./scripts/build_dist.sh réussit
GitHub Actions : au vert sur le dernier commit
Commentaires de revue ouverts : aucun
Ce dont j’ai besoin : confirmation de tout blocage restant du côté du mainteneur

Cela donne immédiatement au mainteneur une question à laquelle il peut répondre.

Si la revue de la boutique officielle est lente, une boutique tierce constitue un canal de distribution valide.

L’écosystème v2 ne se limite pas à un seul dépôt. ZimaOS documente également la configuration d’une boutique tierce pour les dépôts compatibles. Si une application nécessite une distribution communautaire avant une fusion officielle, sa publication par l’intermédiaire d’une boutique tierce maintenue peut constituer une solution pratique tandis que la PR d’origine reste ouverte.

Pour les utilisateurs plutôt que les contributeurs, l’App Store ZimaOS explique le modèle d’applications en un clic et le concept de boutique tierce. La plateforme d’applications ZimaOS présente l’écosystème actuel. Si vous construisez un hôte compact pour tester des applications fortement basées sur Docker, le ZimaBoard 2 est une plateforme de test x86 pertinente, mais il n’est pas nécessaire pour soumettre une application.

FAQ

Le fait de passer la CI signifie-t-il que mon application devrait déjà être fusionnée ?

Non. La CI ne prouve que ce que les workflows automatisés valident. La revue humaine, les règles du dépôt, les commentaires non résolus, les conflits et les décisions des mainteneurs sont des éléments distincts.

Quelle est la commande de validation locale la plus utile pour l’App Store actuelle ?

Le guide de contribution du dépôt renvoie vers ./scripts/build_dist.sh. Confirmez qu’il se termine correctement et génère les fichiers v2 attendus.

Dois-je continuer à modifier le code si toutes les vérifications sont au vert ?

Pas sans raison précise. Commencez par examiner la boîte de fusion et les commentaires de revue. S’il n’y a aucun blocage pouvant être résolu par le contributeur, demandez la décision de revue restante au lieu d’apporter des modifications spéculatives.

Puis-je publier l’application en dehors de la boutique officielle ?

Oui. La documentation v2 actuelle prend explicitement en charge les boutiques ZimaOS tierces compatibles ; une boutique externe peut donc constituer un canal de distribution légitime.