Belangrijkste conclusie: een groene CI-pijplijn bewijst dat de geautomatiseerde controles zijn geslaagd; dat betekent niet dat een pull request voor de App Store is goedgekeurd. Als een CasaOS/ZimaOS-appinzending maandenlang openstaat, blijf dan niet dezelfde badges opnieuw controleren, maar bepaal welke laag nog in behandeling is: repositoryvalidatie, feedback van reviewers, vereisten voor samenvoegen of beoordeling door een maintainer.
Het praktijkvoorbeeld achter deze pagina was uitzonderlijk goed voorbereid: de app was gemigreerd naar de v2-indeling, de controles waren geslaagd, Docker-tags waren vastgezet, de metadata was ingevuld en de bijdrager stelde één eenvoudige vraag: ‘Is er iets dat het samenvoegen blokkeert, of zijn er wijzigingen nodig aan mijn kant?’
Controleer eerst de controles die echt van belang zijn voor de huidige App Store-repository
De huidige bijdragenworkflow van de App Store vraagt bijdragers om de repository te forken, wijzigingen aan te brengen en te testen, en vervolgens een pull request te openen waarin wordt uitgelegd wat er is gewijzigd en hoe dit is gevalideerd.
Voor lokale validatie vraagt de repository bijdragers specifiek om het volgende uit te voeren:
./scripts/build_dist.sh
Een gezond resultaat is specifieker dan ‘mijn composebestand ziet er goed uit’. De build moet zonder fouten worden voltooid en dist/index.jsonen genereer de gewijzigde app onder dist/apps/<app-id>/.
De CI-controles van de App Store in de repository voeren composvalidatie en een volledige v2-buildcontrole uit voor pull requests. Ongeldige YAML, ontbrekende verplichte app-metadata, ontbrekende assets waarnaar wordt verwezen of architectuurverschillen kunnen ervoor zorgen dat de build mislukt.
Groene CI is noodzakelijk, maar bepaalt niet of er wordt samengevoegd
Dit is het punt dat veel bijdragers missen. Een geslaagde geautomatiseerde controle meldt alleen dat de commit voldeed aan de voorwaarden die door die controle zijn getest. GitHub-statuscontroles staan los van beoordelings- en beslissingen over samenvoegen.
Een pull request kan nog steeds openstaan omdat het het volgende nodig heeft:
- een beoordeling door een maintainer of code-eigenaar;
- de gevraagde wijzigingen die moeten worden doorgevoerd;
- de branch die moet worden bijgewerkt;
- een mergeconflict die moet worden opgelost;
- repositoryspecifieke acceptatie- of curatiebeslissingen die CI niet kan nemen.
Vereisten voor het mergen van GitHub behandelt reviews, statuscontroles en branchregels als afzonderlijke mergevoorwaarden.
Gebruik de PR zelf om het knelpunt te identificeren
Controleer vier plaatsen voordat je nog een opmerking “nog nieuws?” plaatst:
- Controles: bevestig dat de nieuwste commit, niet een oudere SHA, de vereiste workflows heeft doorlopen.
- Conversatie: zoek naar onopgeloste opmerkingen van maintainers of verzoeken om wijzigingen.
- Gewijzigde bestanden: controleer of je v2-migratie geen legacy-metadata op de verkeerde locatie heeft achtergelaten.
- Mergevak: GitHub geeft normaal gesproken aan of er nog een review, statuscontrole, conflictresolutie of branch-update vereist is.
Als CI groen is en het mergevak geen door de bijdrager oplosbare blokkade toont, is de volgende stap waarschijnlijk menselijke beoordeling in plaats van nog een codewijziging.
Valideer bij v2-inzendingen het broncontract, niet alleen de Docker-container
Een werkende container is niet automatisch een geldige App Store-vermelding. Het huidige v2-protocol vereist dat de brondefinitie van de app een standaard Docker Compose-runtimeconfiguratie plus een metadata-blok op topniveau met x-casaos bevat. Het x-casaos-metadataschema definieert velden zoals id, main, index, port_map, icon, title, categorie, architectuur en versiegegevens.
Dus wanneer een inzending zegt: “CI geslaagd”, is de nuttige follow-up niet: “is SonarQube geslaagd?”, maar:
- Doet het
./scripts/build_dist.shgeslaagd op de nieuwste branch? - Genereert de app de verwachte v2-uitvoer?
- Zijn alle genoemde pictogrammen, miniaturen en schermafbeeldingen bereikbaar?
- Komt de gedeclareerde architectuur overeen met de image?
- Zijn de versie- en releasegegevens actueel?
- Zijn alle reviewopmerkingen opgelost?
Hoe volg je op zonder ruis te veroorzaken
Als de inzending lange tijd stil is gebleven, plaats dan één korte statusupdate in plaats van de volledige oorspronkelijke toelichting te herhalen. Een nuttige follow-up ziet er zo uit:
PR: #888
Laatste commit: <SHA>
v2-build: ./scripts/build_dist.sh slaagt
GitHub Actions: groen op de laatste commit
Openstaande reviewopmerkingen: geen
Wat ik nodig heb: bevestiging van een resterende blokkade aan de kant van de beheerder
Dat geeft een beheerder onmiddellijk een vraag waarop antwoord kan worden gegeven.
Als de review voor de officiële store traag verloopt, is een externe store een geldig distributiekanaal
Het v2-ecosysteem is niet beperkt tot één repository. ZimaOS documenteert ook de installatie van externe stores voor compatibele repositories. Als een app vóór een officiële merge via de community moet worden verspreid, kan publicatie via een onderhouden externe store een praktisch alternatief zijn terwijl de oorspronkelijke PR open blijft.
Voor gebruikers in plaats van bijdragers legt de ZimaOS App Store het éénklik-appmodel en het concept van externe stores uit. Het ZimaOS-appplatform biedt een actueel overzicht van het ecosysteem. Als je een compacte host bouwt voor het testen van Docker-zware apps, is ZimaBoard 2 een relevant x86-testplatform, maar geen vereiste voor het indienen van een app.
Veelgestelde vragen
Betekent een geslaagde CI dat mijn app al gemerged zou moeten zijn?
Nee. CI bewijst alleen wat de geautomatiseerde workflows valideren. Menselijke review, repositoryregels, onopgeloste opmerkingen, conflicten en beslissingen van beheerders staan daar los van.
Wat is het nuttigste lokale validatiecommando voor de huidige App Store?
De bijdragede van de repository verwijst naar ./scripts/build_dist.sh. Controleer of het proces netjes wordt voltooid en de verwachte v2-bestanden oplevert.
Moet ik code blijven wijzigen als alle controles groen zijn?
Niet zonder een specifieke reden. Inspecteer eerst de mergebox en bekijk de reviewopmerkingen. Als er geen blokkade is die door de bijdrager kan worden opgelost, vraag dan naar de resterende reviewbeslissing in plaats van speculatieve wijzigingen aan te brengen.
Kan ik de app buiten de officiële store publiceren?
Ja. De huidige v2-documentatie ondersteunt expliciet externe ZimaOS-compatibele stores, dus een externe store kan een legitiem distributiekanaal zijn.
