La tua prima build

Questa guida crea, valida, builda e ispeziona un’immagine personalizzata. Una ricetta validata è un controllo di configurazione, non prova che l’ISO sia stata buildata o che ogni comportamento richiesto abbia superato un test VM.

Prima di iniziare

• Accedi così conversazione e build restano collegate al tuo account.
• Inizia con un sistema operativo e un piccolo set di pacchetti o servizi.
• Decidi quale evidenza dimostrerebbe che la richiesta è soddisfatta. Presenza pacchetto, stato servizio, porta in ascolto e comportamento GUI sono asserzioni diverse.

Per una prima esecuzione, evita credenziali e URL repository privati in chat. Aggiungi i segreti dopo tramite il flusso credenziali supportato invece di incorporarli nell’immagine.

1. Dichiara l’esito e i suoi controlli

Esempio:

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.

Esclusioni specifiche aiutano a distinguere un’immagine minima intenzionale da una richiesta che il planner ha semplicemente tralasciato.

2. Ispeziona l’anteprima ricetta

Controlla almeno:

• base_image corrisponde a distribuzione e release richieste;
• i pacchetti richiesti compaiono sotto os.packages o sono forniti da una feature esplicita;
• utenti, gruppi, servizi, rete, installer e scelte desktop corrispondono alla richiesta;
• scenarios contiene i controlli che ti servono davvero;
• non è stato introdotto pacchetto, desktop, installer, credenziale o repository esterno non richiesto.

Chiedi modifiche nella stessa conversazione. Le richieste di follow-up si applicano alla ricetta attiva. Quando si usa Validate Recipe, il backend preserva la richiesta chat sostanziale precedente e blocca la ricetta se mancano ancora requisiti espliciti; la frase di controllo generata non può cancellare l’intento della conversazione.

La validazione può comunque non rilevare un pacchetto non disponibile, un’interruzione upstream, un fallimento build specifico della distro o un comportamento senza test. Leggi l’anteprima come contratto proposto.

3. Avvia la build una volta

Seleziona Start Build sull’anteprima validata. Un clic riuscito crea un ID build. Conserva quell’ID quando segnali un problema; è più affidabile di una percentuale o di uno screenshot da solo.

Il pannello build può mostrare stati come queued, planning, configured, building, finalizing, completed, failed o cancelled. Una build in coda può attendere capacità worker o recovery all’avvio. Una percentuale mostrata è una proiezione di progresso, non una scadenza; alcuni passi di packaging e filesystem richiedono molto più tempo di altri.

Puoi continuare a seguire la build nel pannello live anche se esci dalla vista chat originale. Ricaricare dovrebbe riconnettersi tramite stato build persistito e stream eventi. Non cliccare Start Build ripetutamente salvo che l’UI segnali che nessun ID build è stato creato o la build precedente abbia raggiunto uno stato terminale.

4. Separa completamento immagine e completamento test

Un’immagine può finire prima che la verifica VM selezionata raggiunga uno stato terminale. Leggi entrambi:

• build status: se un artefatto durabile è stato assemblato e finalizzato;
• test status: not_run, running, passed, failed o error;
• certification status, se presente: esito della policy di evidenza configurata, non una certificazione universale di sicurezza o hardware.

Apri i dettagli test. Conferma che ogni asserzione richiesta sia stata eseguita sul guest atteso e ispeziona fallimenti o controlli saltati. Un test di boot superato non prova che un’applicazione si apra; un record pacchetto non prova che il servizio sia sano.

5. Ispeziona e scarica l’artefatto

Prima del download, confronta ricetta finale ed evidenze pacchetti/test con la richiesta. Registra ID build, nome file artefatto, dimensione e checksum se mostrati.

Usa l’azione download della build solo dopo il completamento della finalizzazione artefatto. Il pacchetto di download può contenere l’ISO e evidenze correlate. Se il download restituisce Failed to create download package, not found o un altro errore JSON:

1. conferma di essere autenticato come owner della build;
2. riapri la build esatta, non una scheda conversazione più vecchia;
3. verifica che la finalizzazione artefatto sia completa e l’ISO sia elencata;
4. riprova una volta;
5. segnala ID build, timestamp, stati build/test/finalizzazione mostrati e testo errore esatto.

Non rebuildare solo per aggirare un errore di ownership o packaging; può scartare stato diagnostico utile e consumare un altro slot build.

6. Testa l’ISO nel contesto previsto

Avviare in una VM OpenFactory verifica solo l’ambiente virtuale configurato. Per un desktop installabile, testa anche il percorso installer su un disco usa e getta. Per deploy fisico, testa separatamente modalità firmware, storage, grafica, rete, sospensione, dispositivi di input, aggiornamenti e recovery su hardware rappresentativo.

Percorsi di recovery comuni

Passi successivi

• Capire le ricette
• Schema ricetta
• Asserzioni personalizzate
• Console VNC