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.
Conclusión clave: una canalización de CI en verde demuestra que las comprobaciones automatizadas se superaron correctamente; no significa que se haya aprobado una solicitud de incorporación de cambios de la tienda de aplicaciones. Si una solicitud de envío de una aplicación de CasaOS/ZimaOS lleva meses abierta, deja de comprobar las mismas insignias y determina qué capa sigue pendiente: validación del repositorio, comentarios de los revisores, requisitos de fusión o revisión del mantenedor.
El ejemplo del mundo real en el que se basa esta página estaba excepcionalmente bien preparado: la aplicación se había migrado al formato v2, las comprobaciones estaban en verde, las etiquetas de Docker estaban fijadas, los metadatos estaban completos y el colaborador hacía una pregunta sencilla: «¿Hay algo que bloquee la fusión o algún cambio que deba hacer por mi parte?»
Primero verifica las comprobaciones que realmente importan en el repositorio actual de la tienda de aplicaciones
El flujo de contribución a la tienda de aplicaciones actual pide a los colaboradores que bifurquen el repositorio, realicen y prueben los cambios y, después, abran una solicitud de incorporación de cambios explicando qué cambió y cómo se validó.
./scripts/build_dist.shPara la validación local, el repositorio pide específicamente a los colaboradores que ejecuten: Un resultado correcto es más específico que «mi archivo de Compose parece estar bien». La compilación debe completarse sin errores, produciry generar la aplicación modificada en dist/apps/<app-id>/.
Las comprobaciones de CI de la tienda de aplicaciones del repositorio ejecutan la validación de Compose y una comprobación completa de compilación v2 en las solicitudes de incorporación de cambios. Un YAML no válido, la ausencia de metadatos obligatorios de la aplicación, recursos referenciados inexistentes o incompatibilidades de arquitectura pueden hacer que falle la compilación.
Una CI en verde es necesaria, pero no constituye la decisión de fusión
Este es el punto que muchos colaboradores pasan por alto. Una comprobación automatizada correcta solo indica que el commit cumplió las condiciones que esa comprobación evaluaba. Las comprobaciones de estado de GitHub son independientes de las decisiones de revisión y fusión.
Una solicitud de incorporación de cambios aún puede permanecer abierta porque necesita:
- una revisión del mantenedor o del propietario del código;
- los cambios solicitados que abordar;
- la rama que actualizar;
- un conflicto de fusión que resolver;
- decisiones de aceptación o curación específicas del repositorio que CI no puede tomar.
Los requisitos de combinación de GitHub tratan las revisiones, las comprobaciones de estado y las reglas de la rama como condiciones independientes para combinar una PR.
Usa la propia PR para identificar el bloqueo
Antes de publicar otro comentario de «¿alguna novedad?», comprueba estos cuatro lugares:
- Comprobaciones: confirma que el commit más reciente —no un SHA anterior— haya superado los flujos de trabajo obligatorios.
- Conversación: busca comentarios del mantenedor o solicitudes de cambios sin resolver.
- Archivos modificados: confirma que la migración a v2 no haya dejado metadatos heredados en la ubicación incorrecta.
- Cuadro de combinación: GitHub normalmente indica si todavía se requiere una revisión, una comprobación de estado, resolver conflictos o actualizar la rama.
Si CI aparece en verde y el cuadro de combinación no muestra ningún bloqueo que el colaborador pueda resolver, es probable que el paso restante sea una revisión humana, no otro cambio de código.
Para las propuestas v2, valida el contrato de origen, no solo el contenedor de Docker
Un contenedor funcional no es automáticamente una entrada válida de la App Store. El protocolo v2 actual espera que la definición de la aplicación de origen contenga la configuración de ejecución estándar de Docker Compose, además de un bloque de metadatos x-casaos de nivel superior. El esquema de metadatos x-casaos define campos como id, main, index, port_map, icon, title, categoría, arquitectura y metadatos de versión.
Por eso, cuando una propuesta dice «CI passed», el seguimiento útil no es «¿pasó SonarQube?», sino:
- ¿Lo hace?
./scripts/build_dist.sh¿pasa en la rama más reciente? - ¿La aplicación genera el resultado v2 esperado?
- ¿Se puede acceder a todos los iconos, miniaturas y capturas de pantalla referenciados?
- ¿Coincide la arquitectura declarada con la imagen?
- ¿Están actualizados los metadatos de versión y lanzamiento?
- ¿Se han resuelto todos los comentarios de revisión?
Cómo hacer seguimiento sin generar ruido
Si la propuesta lleva mucho tiempo sin actividad, publica una única actualización de estado concisa en lugar de repetir la propuesta original completa. Un seguimiento útil sería así:
PR: #888
Último commit: <SHA>
Compilación de v2: ./scripts/build_dist.sh se ejecuta correctamente
GitHub Actions: correcto en la última confirmación
Comentarios de revisión abiertos: ninguno
Lo que necesito: confirmación de cualquier bloqueo restante por parte del mantenedorEso proporciona inmediatamente al mantenedor una pregunta que puede responder.
Si la revisión de la tienda oficial es lenta, una tienda de terceros es un canal de distribución válido
El ecosistema de v2 no se limita a un único repositorio. ZimaOS también documenta la configuración de tiendas de terceros para repositorios compatibles. Si una aplicación necesita distribución comunitaria antes de una combinación oficial, publicarla mediante una tienda de terceros mantenida puede ser una alternativa práctica mientras la solicitud de incorporación original siga abierta.
Para los usuarios, no para los contribuidores, la Tienda de aplicaciones de ZimaOS explica el modelo de aplicaciones con un clic y el concepto de tiendas de terceros. La plataforma de aplicaciones de ZimaOS ofrece una visión general del ecosistema actual. Si estás creando un equipo compacto para probar aplicaciones con un uso intensivo de Docker, ZimaBoard 2 es una plataforma de pruebas x86 pertinente, no un requisito para enviar una aplicación.
Preguntas frecuentes
¿Que la CI sea correcta significa que mi aplicación ya debería estar combinada?
No. La CI solo demuestra lo que validan los flujos de trabajo automatizados. La revisión humana, las reglas del repositorio, los comentarios sin resolver, los conflictos y las decisiones de los mantenedores son aspectos independientes.
¿Cuál es el comando de validación local más útil para la App Store actual?
La guía de contribución del repositorio indica ./scripts/build_dist.sh. Confirma que finaliza correctamente y genera los archivos de v2 esperados.
¿Debo seguir cambiando el código si todas las comprobaciones están correctas?
No sin un motivo específico. Primero inspecciona el cuadro de combinación y revisa los comentarios. Si no hay ningún bloqueo que el contribuidor pueda solucionar, solicita la decisión de revisión pendiente en lugar de hacer cambios especulativos.
¿Puedo publicar la aplicación fuera de la tienda oficial?
Sí. La documentación actual de v2 admite explícitamente tiendas de terceros compatibles con ZimaOS, por lo que una tienda externa puede ser un canal de distribución legítimo.
