PR sklepu z aplikacjami CasaOS lub ZimaOS wciąż oczekuje na rozpatrzenie

Najważniejszy wniosek: zielony potok CI dowodzi, że automatyczne kontrole zakończyły się pomyślnie; nie oznacza jednak, że zgłoszenie aplikacji do sklepu w ramach pull requestu zostało zatwierdzone. Jeśli zgłoszenie aplikacji CasaOS/ZimaOS pozostaje otwarte od miesięcy, przestań ponownie sprawdzać te same oznaczenia i ustal, która warstwa nadal oczekuje na działanie: walidacja repozytorium, uwagi recenzenta, wymagania dotyczące scalenia czy przegląd przez opiekuna.

Przykład z rzeczywistego świata, który stał za tą stroną, był wyjątkowo dobrze przygotowany: aplikacja została zmigrowana do formatu v2, kontrole zakończyły się pomyślnie, tagi Dockera były przypięte, metadane uzupełniono, a współtwórca zadawał jedno proste pytanie — „Czy coś blokuje scalenie albo czy muszę wprowadzić jakieś zmiany?”

Najpierw sprawdź kontrole, które mają znaczenie dla bieżącego repozytorium sklepu z aplikacjami

Obecny proces zgłaszania aplikacji do sklepu wymaga od współtwórców utworzenia forka repozytorium, wprowadzenia i przetestowania zmian, a następnie otwarcia pull requestu z wyjaśnieniem, co zostało zmienione i jak przeprowadzono walidację.

W celu lokalnej walidacji repozytorium wymaga od współtwórców uruchomienia:

./scripts/build_dist.sh

Pomyślny wynik jest czymś bardziej szczegółowym niż „mój plik Compose wygląda poprawnie”. Kompilacja powinna zakończyć się bez błędów, wygenerować dist/index.jsoni wygenerować zmienioną aplikację w dist/apps/<app-id>/.

Kontrole CI sklepu z aplikacjami w repozytorium uruchamiają walidację Compose oraz pełną kontrolę kompilacji w wersji 2 dla pull requestów. Nieprawidłowy YAML, brak wymaganych metadanych aplikacji, brak wskazanych zasobów lub niezgodności architektury mogą spowodować niepowodzenie kompilacji.

Zielony CI jest niezbędny, ale nie oznacza decyzji o scaleniu

To kwestia, której wielu współtwórców nie dostrzega. Pomyślne przejście automatycznego testu oznacza tylko, że commit spełnił warunki sprawdzane przez ten test. Kontrole stanu GitHub są niezależne od decyzji dotyczących przeglądu i scalania.

Żądanie pull request może nadal pozostać otwarte, ponieważ wymaga:

przegląd przez opiekuna lub właściciela kodu;
zgłoszone zmiany do wprowadzenia;
gałąź do zaktualizowania;
konflikt scalania do rozwiązania;
decyzje dotyczące akceptacji lub selekcji specyficzne dla repozytorium, których CI nie może podjąć.

Wymagania dotyczące scalania w GitHubie traktują weryfikacje, kontrole statusu i zasady gałęzi jako odrębne warunki scalania.

Użyj samego PR-a, aby zidentyfikować przeszkodę

Zanim opublikujesz kolejny komentarz „czy są jakieś informacje?”, sprawdź cztery miejsca:

Kontrole: upewnij się, że wymagane procesy zakończyły się pomyślnie dla najnowszego commitu, a nie starszego SHA.
Konwersacja: poszukaj nierozstrzygniętych komentarzy opiekunów projektu lub próśb o wprowadzenie zmian.
Zmienione pliki: upewnij się, że migracja do v2 nie pozostawiła starszych metadanych w niewłaściwym miejscu.
Pole scalania: GitHub zazwyczaj informuje, czy nadal wymagana jest weryfikacja, kontrola statusu, rozwiązanie konfliktu lub aktualizacja gałęzi.

Jeśli CI zakończyło się pomyślnie, a pole scalania nie wskazuje żadnej przeszkody, którą może usunąć współtwórca, kolejnym krokiem będzie prawdopodobnie weryfikacja przez człowieka, a nie kolejna zmiana w kodzie.

W przypadku zgłoszeń v2 sprawdzaj zgodność definicji źródłowej, a nie tylko kontener Docker

Działający kontener nie jest automatycznie prawidłowym wpisem w App Store. Obecny protokół v2 wymaga, aby definicja aplikacji źródłowej zawierała standardową konfigurację środowiska uruchomieniowego Docker Compose oraz blok metadanych x-casaos na najwyższym poziomie. Schemat metadanych x-casaos definiuje pola takie jak id, main, index, port_map, icon, title, kategoria, architektura i metadane wersji.

Gdy więc w zgłoszeniu widnieje informacja „CI zakończone pomyślnie”, przydatne uzupełnienie nie brzmi „czy SonarQube zakończyło się pomyślnie?”, lecz:

Czy ./scripts/build_dist.sh Czy najnowsza gałąź przechodzi pomyślnie?
Czy aplikacja generuje oczekiwane dane wyjściowe v2?
Czy wszystkie odwołania do ikon, miniatur i zrzutów ekranu są dostępne?
Czy zadeklarowana architektura odpowiada obrazowi?
Czy metadane wersji i wydania są aktualne?
Czy wszystkie komentarze dotyczące weryfikacji zostały rozwiązane?

Jak uzupełnić zgłoszenie bez tworzenia niepotrzebnego szumu

Jeśli przez długi czas nie ma żadnych informacji dotyczących zgłoszenia, opublikuj jedną zwięzłą aktualizację statusu zamiast powtarzać całą pierwotną prezentację. Przydatne uzupełnienie może wyglądać tak:

PR: #888
Najnowszy commit: <SHA>
Kompilacja v2: ./scripts/build_dist.sh przechodzi pomyślnie
GitHub Actions: zielone przy najnowszym zatwierdzeniu
Otwarte komentarze z przeglądu: brak
Czego potrzebuję: potwierdzenia wszelkich pozostałych blokad po stronie opiekuna

Dzięki temu opiekun od razu otrzymuje pytanie, na które może odpowiedzieć.

Jeśli przegląd w oficjalnym sklepie trwa długo, zewnętrzny sklep jest prawidłowym kanałem dystrybucji

Ekosystem v2 nie ogranicza się do jednego repozytorium. ZimaOS dokumentuje również konfigurację zewnętrznych sklepów dla zgodnych repozytoriów. Jeśli aplikacja potrzebuje dystrybucji społecznościowej przed oficjalnym scaleniem, publikacja za pośrednictwem utrzymywanego zewnętrznego sklepu może być praktyczną alternatywą, podczas gdy pierwotny pull request pozostaje otwarty.

Dla użytkowników, a nie współtwórców, sklep z aplikacjami ZimaOS wyjaśnia model aplikacji instalowanych jednym kliknięciem oraz koncepcję sklepów zewnętrznych. platforma aplikacji ZimaOS przedstawia aktualny przegląd ekosystemu. Jeśli budujesz kompaktowy serwer do intensywnego testowania aplikacji Docker, ZimaBoard 2 jest odpowiednią platformą testową x86, ale nie jest wymagany do przesłania aplikacji.

Najczęściej zadawane pytania

Czy pomyślne przejście CI oznacza, że moja aplikacja powinna już zostać scalona?

Nie. CI potwierdza tylko to, co sprawdzają automatyczne przepływy pracy. Przegląd człowieka, zasady repozytorium, nierozstrzygnięte komentarze, konflikty i decyzje opiekunów to odrębne kwestie.

Jakie lokalne polecenie walidacyjne jest najbardziej przydatne dla obecnego sklepu z aplikacjami?

Przewodnik dotyczący współtworzenia w repozytorium wskazuje na ./scripts/build_dist.sh. Potwierdź, że kończy się poprawnie i tworzy oczekiwane pliki v2.

Czy powinienem nadal zmieniać kod, jeśli wszystkie kontrole przechodzą pomyślnie?

Nie bez konkretnego powodu. Najpierw sprawdź pole scalania i komentarze z przeglądu. Jeśli nie ma blokady, którą może usunąć współtwórca, poproś o pozostałą decyzję dotyczącą przeglądu zamiast wprowadzać spekulatywne zmiany.

Czy mogę opublikować aplikację poza oficjalnym sklepem?

Tak. Aktualna dokumentacja v2 wyraźnie obsługuje sklepy zgodne z ZimaOS prowadzone przez podmioty zewnętrzne, więc zewnętrzny sklep może być prawidłowym kanałem dystrybucji.