Twój pierwszy build

Ten przewodnik tworzy, waliduje, buduje i sprawdza jeden własny obraz. Zweryfikowany przepis to kontrola konfiguracji, a nie dowód, że ISO zostało zbudowane albo że każde żądane zachowanie przeszło test VM.

Zanim zaczniesz

• Zaloguj się, aby rozmowa i build pozostały przypisane do konta.
• Zacznij od jednego systemu operacyjnego i małego zestawu pakietów lub usług.
• Ustal, jaki dowód potwierdzi spełnienie żądania. Obecność pakietu, stan usługi, nasłuchujący port i zachowanie GUI to różne assertions.

Przy pierwszym uruchomieniu unikaj poświadczeń i prywatnych URL repozytoriów na czacie. Sekrety dodaj później przez obsługiwany workflow credential, zamiast wbijać je w obraz.

1. Opisz wynik i kontrole

Przykład:

Build a Debian 13 server image with OpenSSH and curl.
Create a password-locked deploy user in the sudo group.
Verify that the image boots, the deploy user exists, the ssh service is
enabled, and curl is installed. Do not add Docker or a desktop.

Jawne wykluczenia pomagają odróżnić celowo minimalny obraz od żądania, które planner po prostu pominął.

2. Sprawdź podgląd przepisu

Sprawdź co najmniej:

• base_image odpowiada żądanej dystrybucji i wydaniu;
• żądane pakiety są pod os.packages albo dostarcza je jawna feature;
• użytkownicy, grupy, usługi, sieć, installer i wybory desktopu zgadzają się z żądaniem;
• scenarios zawierają kontrole, których naprawdę potrzebujesz;
• nie dodano nieżądanego pakietu, desktopu, installera, credential ani zewnętrznego repozytorium.

Proś o zmiany w tej samej rozmowie. Kolejne żądania trafiają do aktywnego przepisu. Gdy używasz Validate Recipe, backend zachowuje poprzednie merytoryczne żądanie z czatu i blokuje przepis, jeśli brakuje jawnych wymagań; wygenerowane zdanie kontrolne nie może wymazać intencji rozmowy.

Walidacja nadal może pominąć niedostępny pakiet, awarię upstream, błąd buildu specyficzny dla dystrybucji albo zachowanie bez testu. Traktuj podgląd jako proponowaną umowę.

3. Uruchom build raz

Wybierz Start Build na zweryfikowanym podglądzie. Udane kliknięcie tworzy build ID. Zachowaj to ID przy zgłaszaniu problemu; jest bardziej wiarygodne niż sam procent lub zrzut ekranu.

Panel buildu może pokazywać stany takie jak queued, planning, configured, building, finalizing, completed, failed lub cancelled. Build w kolejce może czekać na wolne workery albo odzyskanie po starcie. Wyświetlany procent to projekcja postępu, nie termin; niektóre kroki pakowania i systemu plików trwają dużo dłużej niż inne.

Możesz śledzić build w panelu na żywo, nawet gdy opuścisz pierwotny widok czatu. Odświeżenie powinno połączyć się ponownie przez zapisany stan buildu i strumień zdarzeń. Nie klikaj Start Build wielokrotnie, chyba że UI zgłasza, że nie utworzono build ID albo poprzedni build osiągnął terminal state.

4. Oddziel zakończenie obrazu od zakończenia testów

Obraz może być gotowy, zanim wybrana weryfikacja VM osiągnie terminal state. Sprawdź obie rzeczy:

• build status: czy trwały artefakt został złożony i sfinalizowany;
• test status: not_run, running, passed, failed lub error;
• certification status, gdy występuje: wynik skonfigurowanej polityki evidence, a nie uniwersalna certyfikacja bezpieczeństwa lub sprzętu.

Otwórz szczegóły testu. Potwierdź, że każda żądana assertion uruchomiła się na oczekiwanym gościu, i przejrzyj błędy lub pominięte kontrole. Pozytywny test bootu nie dowodzi, że aplikacja się otwiera; wpis pakietu nie dowodzi, że usługa jest zdrowa.

5. Sprawdź i pobierz artefakt

Przed pobraniem porównaj finalny przepis oraz dowody pakietów i testów z żądaniem. Zapisz build ID, nazwę pliku artefaktu, rozmiar i sumę kontrolną, gdy są widoczne.

Użyj akcji pobierania buildu dopiero po zakończeniu finalizacji artefaktu. Pakiet pobierania może zawierać ISO i powiązane dowody. Jeśli pobieranie zwraca Failed to create download package, not found lub inny błąd JSON:

1. potwierdź, że jesteś zalogowany jako właściciel buildu;
2. otwórz ponownie dokładnie ten build, a nie starszą kartę rozmowy;
3. sprawdź, że finalizacja artefaktu jest ukończona i ISO jest na liście;
4. spróbuj raz ponownie;
5. zgłoś build ID, znacznik czasu, wyświetlane stany buildu, testu i finalizacji oraz dokładny tekst błędu.

Nie buduj ponownie tylko po to, by obejść błąd ownership lub pakowania; to może wyrzucić przydatny stan diagnostyczny i zużyć kolejny slot buildu.

6. Przetestuj ISO w zamierzonym kontekście

Boot w VM OpenFactory weryfikuje tylko skonfigurowane środowisko wirtualne. Dla instalowalnego desktopu przetestuj też ścieżkę installera na jednorazowym dysku. Dla wdrożenia fizycznego osobno sprawdź tryb firmware, storage, grafikę, sieć, suspend, urządzenia wejściowe, aktualizacje i recovery na reprezentatywnym sprzęcie.

Typowe ścieżki naprawy

Następne kroki

• Zrozumienie przepisów
• Schemat przepisu
• Własne assertions
• Konsola VNC