Votre premier build

Ce guide crée, valide, construit et inspecte une image personnalisée. Une recette validée est une vérification de configuration, pas une preuve que l’ISO a été construite ou que chaque comportement demandé a réussi un test VM.

Avant de commencer

• Connectez-vous pour que la conversation et le build restent attachés à votre compte.
• Commencez avec un système d’exploitation et un petit ensemble de paquets ou services.
• Décidez quelles preuves montreraient que la demande est satisfaite. La présence d’un paquet, l’état d’un service, un port en écoute et le comportement GUI sont des assertions distinctes.

Pour une première exécution, évitez identifiants et URL de dépôt privé dans le chat. Ajoutez les secrets plus tard via le workflow d’identifiants supporté plutôt que de les intégrer dans l’image.

1. Formuler le résultat et ses vérifications

Exemple :

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.

Des exclusions explicites aident à distinguer une image minimale voulue d’une demande que le planificateur aurait simplement omise.

2. Inspecter l’aperçu de recette

Vérifiez au minimum :

• base_image correspond à la distribution et la version demandées ;
• les paquets demandés apparaissent sous os.packages ou sont fournis par une fonctionnalité explicite ;
• utilisateurs, groupes, services, réseau, installateur et choix de bureau correspondent à la demande ;
• scenarios contient les vérifications dont vous avez réellement besoin ;
• aucun paquet, bureau, installateur, identifiant ou dépôt externe non demandé n’a été introduit.

Demandez des changements dans la même conversation. Les demandes de suivi s’appliquent à la recette active. Lorsque Validate Recipe est utilisé, le backend conserve la demande substantive de chat précédente et bloque la recette si des exigences explicites manquent encore ; la phrase de contrôle générée ne peut pas effacer l’intention de la conversation.

La validation peut encore manquer un paquet indisponible, une panne amont, une défaillance de build propre à la distro ou un comportement sans test. Lisez l’aperçu comme un contrat proposé.

3. Lancer le build une fois

Sélectionnez Start Build sur l’aperçu validé. Un clic réussi crée un ID de build. Conservez cet ID pour signaler un problème ; il est plus fiable qu’un pourcentage ou une capture seule.

Le panneau de build peut afficher des états comme queued, planning, configured, building, finalizing, completed, failed ou cancelled. Un build en file peut attendre de la capacité worker ou une reprise au démarrage. Un pourcentage affiché est une projection de progression, pas une échéance ; certaines étapes d’empaquetage et de système de fichiers prennent beaucoup plus de temps que d’autres.

Vous pouvez continuer à suivre le build dans son panneau live même si vous quittez la vue chat d’origine. Un rechargement devrait se reconnecter via l’état de build persisté et le flux d’événements. Ne cliquez pas Start Build plusieurs fois sauf si l’interface signale qu’aucun ID de build n’a été créé ou que le build précédent a atteint un état terminal.

4. Séparer l’achèvement de l’image et celui des tests

Une image peut se terminer avant que la vérification VM sélectionnée n’atteigne un état terminal. Lisez les deux :

• build status : si un artefact durable a été assemblé et finalisé ;
• test status : not_run, running, passed, failed ou error ;
• certification status, lorsqu’il est présent : le résultat de la politique de preuve configurée, pas une certification universelle de sécurité ou matérielle.

Ouvrez le détail des tests. Confirmez que chaque assertion demandée a tourné contre l’invité attendu et inspectez échecs ou vérifications ignorées. Un test de boot réussi ne prouve pas qu’une application s’ouvre ; un enregistrement de paquet ne prouve pas que son service est sain.

5. Inspecter et télécharger l’artefact

Avant le téléchargement, comparez la recette finale et les preuves paquets/tests avec la demande. Notez l’ID de build, le nom de fichier de l’artefact, la taille et la somme de contrôle lorsqu’elles sont affichées.

Utilisez l’action de téléchargement du build uniquement après l’achèvement de la finalisation de l’artefact. Le paquet de téléchargement peut contenir l’ISO et les preuves associées. Si le téléchargement renvoie Failed to create download package, not found ou une autre erreur JSON :

1. confirmez que vous êtes connecté en tant que propriétaire du build ;
2. rouvrez le build exact plutôt qu’une ancienne carte de conversation ;
3. vérifiez que la finalisation de l’artefact est terminée et que l’ISO est listée ;
4. réessayez une fois ;
5. signalez l’ID de build, l’horodatage, les états build/test/finalization affichés et le texte d’erreur exact.

Ne relancez pas un build uniquement pour contourner une erreur de propriété ou d’empaquetage ; cela peut jeter un état diagnostique utile et consommer un autre slot de build.

6. Tester l’ISO dans son contexte prévu

Démarrer dans la VM OpenFactory ne vérifie que l’environnement virtuel configuré. Pour un bureau installable, testez aussi le chemin installateur sur un disque jetable. Pour un déploiement physique, testez séparément le mode firmware, le stockage, les graphiques, le réseau, la veille, les périphériques d’entrée, les mises à jour et la reprise sur du matériel représentatif.

Chemins de reprise courants

Étapes suivantes

• Comprendre les recettes
• Schéma de recette
• Assertions personnalisées
• Console VNC