Viktig slutsats: en grön CI-pipeline visar att de automatiserade kontrollerna godkändes, men det betyder inte att en pull request till App Store har godkänts. Om en CasaOS/ZimaOS-appinlämning har varit öppen i flera månader bör du sluta kontrollera samma statusmarkeringar och ta reda på vilket lager som fortfarande väntar: validering av kodarkivet, återkoppling från granskare, krav för sammanfogning eller granskning av en underhållare.
Det verkliga exemplet bakom den här sidan var ovanligt väl förberett: appen hade migrerats till v2-formatet, kontrollerna var gröna, Docker-taggarna var låsta, metadata var ifyllda och bidragsgivaren ställde en enkel fråga – ”Finns det något som blockerar sammanfogningen eller några ändringar som behövs från min sida?”
Verifiera först de kontroller som faktiskt är relevanta för det aktuella App Store-kodarkivet
Det aktuella arbetsflödet för bidrag till App Store ber bidragsgivare att skapa en fork av kodarkivet, göra och testa ändringar och sedan öppna en pull request med en förklaring av vad som ändrats och hur det har validerats.
För lokal validering ber kodarkivet specifikt bidragsgivare att köra:
./scripts/build_dist.shEtt godkänt resultat är mer specifikt än att ”min Compose-fil ser korrekt ut”. Bygget ska slutföras utan fel, skapa dist/index.jsonoch generera den ändrade appen under dist/apps/<app-id>/.
App Stores CI-kontroller i kodarkivet kör Compose-validering och en fullständig v2-byggkontroll för pull requests. Ogiltig YAML, saknade obligatoriska appmetadata, saknade refererade resurser eller arkitekturmismatchningar kan göra att bygget misslyckas.
En grön CI-körning är nödvändig, men den avgör inte om ändringen sammanfogas
Det här är vad många bidragsgivare missar. En godkänd automatiserad kontroll visar bara att commiten uppfyllde villkoren som testades av kontrollen. GitHubs statuskontroller är separata från beslut om granskning och sammanfogning.
En pull request kan fortfarande förbli öppen eftersom den behöver:
- en granskning av en underhållare eller kodägare;
- begärda ändringar som behöver åtgärdas;
- grenen som behöver uppdateras;
- en mergekonflikt som behöver lösas;
- arkivspecifika beslut om godkännande eller kuratering som CI inte kan fatta.
Krav för sammanslagning på GitHub behandlar granskningar, statuskontroller och grenregler som separata villkor för sammanslagning.
Använd själva PR:et för att identifiera hindret
Innan du publicerar ännu en kommentar med ”någon uppdatering?”, kontrollera fyra ställen:
- Kontroller: bekräfta att den senaste commiten – inte en äldre SHA – har klarat de obligatoriska arbetsflödena.
- Konversation: leta efter olösta underhållarkommentarer eller ändringsbegäranden.
- Ändrade filer: bekräfta att v2-migreringen inte lämnade äldre metadata på fel plats.
- Sammanslagningsruta: GitHub visar normalt om en granskning, statuskontroll, konfliktlösning eller uppdatering av grenen fortfarande krävs.
Om CI är grön och sammanslagningsrutan inte visar något hinder som bidragsgivaren kan åtgärda, är nästa steg sannolikt mänsklig granskning snarare än ännu en kodändring.
För v2-bidrag ska du validera källkontraktet – inte bara Docker-containern
En fungerande container är inte automatiskt en giltig App Store-post. Det aktuella v2-protokollet förutsätter att appens källdefinition innehåller standardkonfiguration för Docker Compose-körning samt ett metadata-block på toppnivå med x-casaos. Schemaspecifikationen för x-casaos-metadata definierar fält som id, main, index, port_map, icon, title, kategori, arkitektur och versionsmetadata.
Så när ett bidrag säger ”CI godkändes” är den användbara uppföljningen inte ”godkändes SonarQube?” utan:
- Gör
./scripts/build_dist.shgodkänd på den senaste grenen? - Genererar appen det förväntade v2-resultatet?
- Är alla refererade ikoner, miniatyrbilder och skärmbilder tillgängliga?
- Stämmer den deklarerade arkitekturen överens med avbildningen?
- Är versions- och utgåvemetadata aktuella?
- Har alla granskningskommentarer åtgärdats?
Så följer du upp utan att skapa brus
Om bidraget har varit tyst under en längre tid, publicera en kort statusuppdatering i stället för att upprepa hela den ursprungliga presentationen. En användbar uppföljning kan se ut så här:
PR: #888
Senaste commit: <SHA>
v2-bygge: ./scripts/build_dist.sh slutförs utan fel.
GitHub Actions: grönt för den senaste commiten
Öppna granskningskommentarer: inga
Det jag behöver: bekräftelse på eventuella återstående hinder på underhållarsidanDet ger en underhållare en fråga som omedelbart kan besvaras.
Om granskningen av den officiella butiken går långsamt är en tredjepartsbutik en giltig distributionsväg
v2-ekosystemet är inte begränsat till ett enda arkiv. ZimaOS dokumenterar också konfiguration av tredjepartsbutik för kompatibla arkiv. Om en app behöver communitydistribution innan en officiell sammanslagning kan publicering via en underhållen tredjepartsbutik vara ett praktiskt alternativ medan det ursprungliga pull requestet fortfarande är öppet.
För användare snarare än bidragsgivare förklarar ZimaOS appbutik modellen med appar i ett klick och konceptet med tredjepartsbutiker. ZimaOS appplattform ger en aktuell översikt över ekosystemet. Om du bygger en kompakt värd för intensiv apptestning med Docker är ZimaBoard 2 en relevant x86-testplattform, men den krävs inte för att skicka in en app.
Vanliga frågor
Betyder godkänd CI att min app redan bör ha slagits samman?
Nej. CI bevisar bara det som de automatiserade arbetsflödena validerar. Manuell granskning, projektregler, olösta kommentarer, konflikter och underhållarnas beslut är separata frågor.
Vilket lokalt valideringskommando är mest användbart för den aktuella appbutiken?
Projektets bidragsguide hänvisar till ./scripts/build_dist.sh. Bekräfta att den slutförs utan fel och skapar de förväntade v2-filerna.
Bör jag fortsätta ändra koden om alla kontroller är gröna?
Inte utan ett särskilt skäl. Inspektera först sammanslagningsrutan och granskningskommentarerna. Om det inte finns något hinder som bidragsgivaren kan åtgärda, be om det återstående granskningsbeslutet i stället för att göra spekulativa ändringar.
Kan jag publicera appen utanför den officiella butiken?
Ja. Den aktuella v2-dokumentationen stöder uttryckligen ZimaOS-kompatibla tredjepartsbutiker, så en extern butik kan vara en legitim distributionsväg.
