Primul build

Acest ghid creează, validează, construiește și inspectează o imagine personalizată. O rețetă validată este o verificare de configurație, nu dovada că ISO-ul a fost construit sau că fiecare comportament cerut a trecut un test VM.

Înainte să începeți

• Autentificați-vă ca conversația și build-ul să rămână legate de contul dvs.
• Începeți cu un sistem de operare și un set mic de pachete sau servicii.
• Decideți ce dovadă ar arăta că cererea a fost îndeplinită. Prezența unui pachet, starea unui serviciu, un port în ascultare și comportamentul GUI sunt assertion diferite.

La prima rulare, evitați credențialele și URL-urile de depozite private în chat. Adăugați secretele mai târziu prin workflow-ul suportat pentru credentials, nu integrate în imagine.

1. Stabiliți rezultatul și verificările

Exemplu:

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.

Excluderile explicite ajută la distingerea unei imagini minimale intenționate de o cerere pe care planner-ul a omis-o pur și simplu.

2. Inspectați previzualizarea rețetei

Verificați cel puțin:

• base_image corespunde distribuției și lansării cerute;
• pachetele cerute apar sub os.packages sau sunt furnizate de o feature explicită;
• utilizatorii, grupurile, serviciile, rețeaua, installer-ul și alegerile de desktop corespund cererii;
• scenarios conțin verificările de care aveți nevoie;
• nu s-a introdus pachet, desktop, installer, credential sau depozit extern necerut.

Cereți modificări în aceeași conversație. Cererile ulterioare se aplică rețetei active. Când se folosește Validate Recipe, backend-ul păstrează cererea substanțială anterioară din chat și blochează rețeta dacă lipsesc încă cerințe explicite; propoziția de control generată nu poate șterge intenția conversației.

Validarea poate totuși rata un pachet indisponibil, o întrerupere upstream, o eșec de build specific distro-ului sau un comportament fără test. Citiți previzualizarea ca un contract propus.

3. Porniți build-ul o singură dată

Pe previzualizarea validată, selectați Start Build. Un clic reușit creează un build ID. Păstrați acel ID când raportați o problemă; este mai fiabil decât un procent sau o captură de ecran.

Panoul de build poate afișa stări queued, planning, configured, building, finalizing, completed, failed sau cancelled. Un build în coadă poate aștepta capacitate worker sau recuperare după pornire. Procentul afișat este o proiecție a progresului, nu un termen; unii pași de ambalare și de sistem de fișiere durează mult mai mult decât alții.

Puteți urmări build-ul în panoul live chiar dacă părăsiți vizualizarea inițială a chat-ului. Reîncărcarea ar trebui să se reconecteze prin starea persistată a build-ului și event stream. Nu faceți clic repetat pe Start Build decât dacă UI-ul raportează că nu s-a creat build ID sau că build-ul anterior a atins o stare terminală.

4. Separați finalizarea imaginii de finalizarea testelor

Imaginea se poate termina înainte ca verificarea VM selectată să atingă o stare terminală. Citiți ambele:

• build status: dacă un artefact durabil a fost asamblat și finalizat;
• test status: not_run, running, passed, failed sau error;
• certification status, când este prezent: rezultatul policy-ului de evidence configurat, nu o certificare universală de securitate sau hardware.

Deschideți detaliile testelor. Confirmați că fiecare assertion cerută a rulat pe invitatul așteptat și inspectați eșecurile sau verificările sărite. Un test de boot reușit nu dovedește că o aplicație se deschide; o înregistrare de pachet nu dovedește că serviciul este sănătos.

5. Inspectați și descărcați artefactul

Înainte de descărcare, comparați rețeta finală și dovada pachetelor/testelor cu cererea. Notați build ID, numele fișierului artefact, dimensiunea și checksum când sunt afișate.

Folosiți acțiunea de descărcare a build-ului doar după ce finalizarea artefactului s-a încheiat. Pachetul de descărcare poate conține ISO-ul și dovada asociată. Dacă descărcarea returnează Failed to create download package, not found sau altă eroare JSON:

1. confirmați că sunteți autentificat ca proprietar al build-ului;
2. redeschideți exact acel build, nu o carte de conversație mai veche;
3. verificați că finalizarea artefactului este completă și ISO-ul este listat;
4. reîncercați o dată;
5. raportați build ID, marcaj temporal, stările afișate build/test/finalizare și textul exact al erorii.

Nu reconstruiți doar pentru a ocoli o eroare de proprietate sau ambalare; puteți pierde stare diagnostic utilă și consuma un alt slot de build.

6. Testați ISO-ul în contextul prevăzut

Pornirea în VM OpenFactory verifică doar mediul virtual configurat. Pentru un desktop instalabil, testați separat calea installer-ului pe un disc de unică folosință. Pentru deploy fizic, testați separat modul firmware, stocarea, grafica, rețeaua, suspend, dispozitivele de intrare, actualizările și recuperarea pe hardware reprezentativ.

Căi uzuale de recuperare

Pași următori

• Înțelegerea rețetelor
• Schema rețetei
• Assertion personalizate
• Consola VNC