Ihr erster Build

Diese Anleitung erstellt, validiert, baut und inspiziert ein eigenes Image. Ein validiertes Rezept ist eine Konfigurationsprüfung, kein Nachweis, dass das ISO gebaut wurde oder jedes angeforderte Verhalten einen VM-Test bestanden hat.

Bevor Sie starten

• Melden Sie sich an, damit Konversation und Build an Ihr Konto gebunden bleiben.
• Starten Sie mit einem Betriebssystem und einer kleinen Menge Pakete oder Dienste.
• Legen Sie fest, welcher Nachweis die Anfrage erfüllt. Paketpräsenz, Dienstzustand, lauschender Port und GUI-Verhalten sind unterschiedliche Assertions.

Vermeiden Sie beim ersten Lauf Zugangsdaten und private Repository-URLs im Chat. Fügen Sie Geheimnisse später über den unterstützten Credential-Workflow hinzu, statt sie ins Image zu backen.

1. Ergebnis und Checks benennen

Beispiel:

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.

Explizite Ausschlüsse helfen, ein absichtlich minimales Image von einer Anfrage zu unterscheiden, die der Planner schlicht übersehen hat.

2. Rezept-Vorschau prüfen

Prüfen Sie mindestens:

• base_image entspricht der angeforderten Distribution und Version;
• angeforderte Pakete stehen unter os.packages oder kommen über ein explizites Feature;
• Benutzer, Gruppen, Dienste, Netzwerk, Installer und Desktop passen zur Anfrage;
• scenarios enthalten die Checks, die Sie wirklich brauchen;
• es wurde kein ungefordertes Paket, Desktop, Installer, Credential oder externes Repository eingeführt.

Fordern Sie Änderungen in derselben Konversation an. Folgeanfragen gelten für das aktive Rezept. Bei Validate Recipe bewahrt das Backend die vorherige inhaltliche Chat-Anfrage und blockiert das Rezept, wenn explizite Anforderungen noch fehlen; der generierte Steuersatz darf die Absicht der Konversation nicht löschen.

Validierung kann weiterhin ein nicht verfügbares Paket, einen Upstream-Ausfall, einen distro-spezifischen Build-Fehler oder Verhalten ohne Test übersehen. Lesen Sie die Vorschau als vorgeschlagenen Vertrag.

3. Build einmal starten

Wählen Sie Start Build auf der validierten Vorschau. Ein erfolgreicher Klick erzeugt eine Build-ID. Behalten Sie diese ID bei Problemen; sie ist zuverlässiger als nur ein Prozentsatz oder Screenshot.

Das Build-Panel kann Zustände wie queued, planning, configured, building, finalizing, completed, failed oder cancelled anzeigen. Ein Build in der Warteschlange wartet ggf. auf Worker-Kapazität oder Startup-Recovery. Ein angezeigter Prozentsatz ist eine Fortschrittsprojektion, keine Frist; manche Packaging- und Dateisystem-Schritte dauern deutlich länger als andere.

Sie können den Build im Live-Build-Panel weiter verfolgen, auch wenn Sie die ursprüngliche Chat-Ansicht verlassen. Ein Reload sollte über persistierten Build-Zustand und Event-Stream wieder verbinden. Klicken Sie Start Build nicht wiederholt, es sei denn, die UI meldet, dass keine Build-ID erzeugt wurde oder der vorherige Build einen terminalen Zustand erreicht hat.

4. Image-Abschluss von Test-Abschluss trennen

Ein Image kann fertig sein, bevor die ausgewählte VM-Verifikation einen terminalen Zustand erreicht. Lesen Sie beides:

• build status: ob ein dauerhaftes Artefakt zusammengestellt und finalisiert wurde;
• test status: not_run, running, passed, failed oder error;
• certification status, sofern vorhanden: Ergebnis der konfigurierten Evidenz-Policy, keine universelle Sicherheits- oder Hardware-Zertifizierung.

Öffnen Sie Test-Details. Bestätigen Sie, dass jede angeforderte Assertion gegen den erwarteten Gast lief, und prüfen Sie Fehler oder übersprungene Checks. Ein bestandener Boot-Test beweist nicht, dass eine Anwendung öffnet; ein Paketdatensatz beweist nicht, dass der Dienst gesund ist.

5. Artefakt prüfen und herunterladen

Vergleichen Sie vor dem Download finales Rezept sowie Paket-/Test-Nachweis mit der Anfrage. Notieren Sie Build-ID, Artefakt-Dateiname, Größe und Prüfsumme, wenn angezeigt.

Nutzen Sie die Download-Aktion des Builds erst nach abgeschlossener Artefakt-Finalisierung. Das Download-Paket kann ISO und zugehörigen Nachweis enthalten. Liefert der Download Failed to create download package, not found oder einen anderen JSON-Fehler:

1. bestätigen Sie, dass Sie als Build-Owner angemeldet sind;
2. öffnen Sie exakt diesen Build, nicht eine ältere Konversations-Karte;
3. prüfen Sie, dass Artefakt-Finalisierung abgeschlossen ist und das ISO gelistet ist;
4. einmal erneut versuchen;
5. melden Sie Build-ID, Zeitstempel, angezeigte Build-/Test-/Finalisierungs-Zustände und exakten Fehlertext.

Bauen Sie nicht neu nur wegen Ownership- oder Packaging-Fehler; das kann nützlichen Diagnosezustand verwerfen und einen weiteren Build-Slot verbrauchen.

6. ISO im beabsichtigten Kontext testen

Boot in OpenFactorys VM verifiziert nur die konfigurierte virtuelle Umgebung. Für einen installierbaren Desktop testen Sie zusätzlich den Installer-Pfad auf einer Wegwerf-Disk. Für physisches Deployment testen Sie getrennt Firmware-Modus, Speicher, Grafik, Netzwerk, Suspend, Eingabegeräte, Updates und Recovery auf repräsentativer Hardware.

Typische Recovery-Pfade

Nächste Schritte

• Rezepte verstehen
• Rezept-Schema
• Eigene Assertions
• VNC-Konsole