CasaOS- oder ZimaOS-App-Store-PR noch ausstehend

Wichtiges Fazit: Eine erfolgreiche CI-Pipeline belegt, dass die automatisierten Prüfungen bestanden wurden; sie bedeutet nicht, dass ein Pull Request für den App Store genehmigt wurde. Wenn eine CasaOS-/ZimaOS-App-Einreichung monatelang offen ist, solltest du nicht weiterhin dieselben Statusanzeigen überprüfen, sondern feststellen, welche Ebene noch aussteht: Repository-Validierung, Feedback der Reviewer, Merge-Anforderungen oder Überprüfung durch einen Maintainer.

Das reale Beispiel hinter dieser Seite war ungewöhnlich gut vorbereitet: Die App war in das v2-Format migriert worden, die Prüfungen waren erfolgreich, Docker-Tags waren fest verankert, die Metadaten waren vollständig, und der Mitwirkende stellte eine einfache Frage: „Gibt es etwas, das den Merge verhindert, oder sind von meiner Seite Änderungen erforderlich?“

Überprüfe zunächst die Prüfungen, die für das aktuelle App-Store-Repository tatsächlich relevant sind.

Der aktuelle Beitragsworkflow des App Store sieht vor, dass Mitwirkende das Repository forken, Änderungen vornehmen und testen und anschließend einen Pull Request eröffnen, in dem sie erklären, was geändert wurde und wie dies validiert wurde.

Für die lokale Validierung fordert das Repository Mitwirkende ausdrücklich dazu auf, Folgendes auszuführen:

./scripts/build_dist.sh

Ein erfolgreiches Ergebnis ist spezifischer als „Meine Compose-Datei sieht korrekt aus.“ Der Build sollte ohne Fehler abgeschlossen werden und dist/index.jsonund die geänderte App unter dist/apps/<app-id>/.

Die CI-Prüfungen des App Store im Repository führen bei Pull Requests eine Compose-Validierung und eine vollständige v2-Bauprüfung durch. Ungültiges YAML, fehlende erforderliche App-Metadaten, fehlende referenzierte Assets oder Architekturunterschiede können dazu führen, dass der Build fehlschlägt.

Eine erfolgreiche CI ist notwendig, aber sie entscheidet nicht über den Merge.

Das ist der Punkt, den viele Mitwirkende übersehen. Eine erfolgreiche automatisierte Prüfung meldet lediglich, dass der Commit die von dieser Prüfung getesteten Bedingungen erfüllt hat. GitHub-Statusprüfungen sind von Überprüfungs- und Merge-Entscheidungen unabhängig.

Ein Pull Request kann weiterhin offen bleiben, weil er Folgendes benötigt:

eine Überprüfung durch einen Maintainer oder Code-Eigentümer;
angeforderte Änderungen, die umgesetzt werden müssen;
der Branch, der auf den neuesten Stand gebracht werden muss;
ein Merge-Konflikt, der gelöst werden muss;
Repository-spezifische Annahme- oder Kurationsentscheidungen, die CI nicht treffen kann.

Die GitHub-Anforderungen für das Zusammenführen behandeln Reviews, Statuschecks und Branch-Regeln als separate Bedingungen für das Zusammenführen.

Nutze den PR selbst, um den Blocker zu ermitteln

Bevor du einen weiteren Kommentar mit „Gibt es Neuigkeiten?“ veröffentlichst, überprüfe vier Stellen:

Checks: Bestätige, dass der neueste Commit – nicht eine ältere SHA – die erforderlichen Workflows bestanden hat.
Unterhaltung: Suche nach ungelösten Kommentaren oder Änderungswünschen von Maintainerinnen und Maintainer.
Geänderte Dateien: Bestätige, dass deine v2-Migration keine Legacy-Metadaten am falschen Ort hinterlassen hat.
Merge-Feld: GitHub zeigt normalerweise an, ob noch eine Prüfung, ein Statuscheck, eine Konfliktlösung oder eine Aktualisierung des Branches erforderlich ist.

Wenn CI grün ist und das Merge-Feld keinen von Mitwirkenden behebbaren Blocker anzeigt, ist der nächste Schritt wahrscheinlich eine manuelle Prüfung und keine weitere Codeänderung.

Bei v2-Beiträgen solltest du den Quellvertrag validieren – nicht nur den Docker-Container

Ein funktionierender Container ist nicht automatisch ein gültiger App-Store-Eintrag. Das aktuelle v2-Protokoll erwartet, dass die Quelldefinition der App eine standardmäßige Docker-Compose-Laufzeitkonfiguration sowie einen Metadatenblock x-casaos auf oberster Ebene enthält. Das Metadatenschema für x-casaos definiert Felder wie id, main, index, port_map, icon, title, Kategorie, Architektur und Versionsmetadaten.

Wenn in einem Beitrag also steht „CI bestanden“, lautet die hilfreiche Nachfrage nicht „Hat SonarQube bestanden?“, sondern:

Erfüllt ./scripts/build_dist.sh im neuesten Branch bestanden?
Erzeugt die App die erwartete v2-Ausgabe?
Sind alle referenzierten Symbole, Vorschaubilder und Screenshots erreichbar?
Stimmt die deklarierte Architektur mit dem Image überein?
Sind Versions- und Release-Metadaten aktuell?
Sind alle Review-Kommentare erledigt?

So fragst du nach, ohne unnötiges Rauschen zu erzeugen

Wenn der Beitrag lange Zeit unbeachtet geblieben ist, veröffentliche statt der vollständigen ursprünglichen Vorstellung ein kurzes Statusupdate. Eine hilfreiche Nachfrage sieht etwa so aus:

PR: #888
Letzter Commit: <SHA>
v2-Build: ./scripts/build_dist.sh erfolgreich
GitHub Actions: beim neuesten Commit erfolgreich
Offene Review-Kommentare: keine
Was ich benötige: Bestätigung, ob auf Seiten der Maintainer noch ein Blocker besteht

Damit erhält ein Maintainer sofort eine konkrete Frage, die er beantworten kann.

Wenn die Prüfung im offiziellen Store langsam vorangeht, ist ein Store eines Drittanbieters ein gültiger Vertriebsweg.

Das v2-Ökosystem ist nicht auf ein einziges Repository beschränkt. ZimaOS dokumentiert außerdem die Einrichtung von Stores Drittanbieter für kompatible Repositories. Wenn eine App vor einem offiziellen Merge über die Community verteilt werden soll, kann die Veröffentlichung über einen gepflegten Store eines Drittanbieters eine praktische Alternative sein, während der ursprüngliche PR offen bleibt.

Für Nutzer und nicht für Mitwirkende erklärt der ZimaOS App Store das Ein-Klick-App-Modell und das Konzept der Stores von Drittanbietern. Die ZimaOS-App-Plattform bietet einen aktuellen Überblick über das Ökosystem. Wenn du einen kompakten Host zum Testen Docker-intensiver Apps einrichtest, ist das ZimaBoard 2 eine geeignete x86-Testplattform, aber keine Voraussetzung für das Einreichen einer App.

FAQ

Bedeutet eine erfolgreiche CI, dass meine App bereits gemergt werden sollte?

Nein. CI belegt nur, was durch die automatisierten Workflows validiert wird. Die menschliche Prüfung, Repository-Regeln, ungelöste Kommentare, Konflikte und Entscheidungen der Maintainer sind davon unabhängig.

Welcher lokale Validierungsbefehl ist für den aktuellen App Store am nützlichsten?

Der Contributing-Leitfaden des Repositorys verweist auf ./scripts/build_dist.sh. Bestätige, dass der Vorgang sauber abgeschlossen wird und die erwarteten v2-Dateien erzeugt.

Soll ich den Code weiter ändern, wenn alle Prüfungen erfolgreich sind?

Nicht ohne einen konkreten Grund. Prüfe zuerst die Merge-Box und die Review-Kommentare. Wenn es keinen vom Mitwirkenden behebbaren Blocker gibt, frage nach der noch ausstehenden Review-Entscheidung, statt spekulative Änderungen vorzunehmen.

Kann ich die App außerhalb des offiziellen Stores veröffentlichen?

Ja. Die aktuelle v2-Dokumentation unterstützt ausdrücklich mit ZimaOS kompatible Stores von Drittanbietern, sodass ein externer Store ein legitimer Vertriebsweg sein kann.