Ваша перша збірка

Цей walkthrough створює, валідує, збирає та переглядає один власний образ. Валідований рецепт , перевірка конфігурації, а не доказ, що ISO зібрано або що кожна запитана поведінка пройшла VM-тест.

Перед початком

• Увійдіть, щоб розмова й збірка залишилися прив’язаними до вашого облікового запису.
• Почніть з однієї операційної системи та невеликого набору пакетів або сервісів.
• Визначте, які докази підтвердять виконання запиту. Наявність пакета, стан сервісу, порт у listen і поведінка GUI , різні assertions.

У першому запуску уникайте облікових даних і URL приватних репозиторіїв у чаті. Секрети додавайте пізніше через підтримуваний credential workflow, а не вбудовуйте в образ.

1. Сформулюйте результат і його перевірки

Приклад:

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.

Явні виключення допомагають відрізнити навмисний мінімальний образ від запиту, який planner просто пропустив.

2. Перегляньте попередній перегляд рецепта

Перевірте щонайменше:

• base_image відповідає запитаному дистрибутиву та релізу;
• запитані пакети є під os.packages або надаються явною feature;
• користувачі, групи, сервіси, мережа, installer, desktop відповідають запиту;
• scenarios містять потрібні перевірки;
• не додано незапитаних пакетів, desktop, installer, credentials або зовнішніх репозиторіїв.

Зміни просіть у тій самій розмові. Наступні запити застосовуються до активного рецепта. Коли використовується Validate Recipe, backend зберігає попередній змістовний chat request і блокує рецепт, якщо явні вимоги ще відсутні; згенероване контрольне речення не може стерти намір розмови.

Валідація все одно може пропустити недоступний пакет, збій upstream, distro-specific помилку збірки або поведінку без тесту. Читайте preview як запропонований контракт.

3. Запустіть збірку один раз

Оберіть Start Build на валідованому preview. Успішний клік створює build ID. Зберігайте цей ID при повідомленні про проблему; він надійніший за відсоток або один скріншот.

Панель збірки може показувати стани queued, planning, configured, building, finalizing, completed, failed або cancelled. Збірка в queued може чекати worker capacity або startup recovery. Показаний відсоток , проекція прогресу, не дедлайн; деякі кроки пакування та файлової системи тривають набагато довше за інші.

Можна стежити за збіркою в live build panel, навіть якщо ви покинули початковий chat view. Перезавантаження має перепідключитися через збережений стан збірки та event stream. Не натискайте Start Build повторно, якщо UI не повідомляє, що build ID не створено або попередня збірка досягла terminal state.

4. Розділіть завершення образу та завершення тестів

Образ може завершитися раніше, ніж обрана VM-верифікація досягне terminal state. Читайте обидва:

• build status: чи зібрано та фіналізовано стійкий артефакт;
• test status: not_run, running, passed, failed або error;
• certification status, де є: результат налаштованої evidence policy, а не універсальна сертифікація безпеки чи обладнання.

Відкрийте деталі тестів. Переконайтеся, що кожна запитана assertion виконана на очікуваному guest, і перегляньте відмови або пропущені перевірки. Успішний boot test не доводить, що застосунок відкривається; запис пакета не доводить, що його сервіс здоровий.

5. Перегляньте та завантажте артефакт

Перед завантаженням порівняйте фінальний рецепт і докази пакетів/тестів із запитом. Зафіксуйте build ID, ім’я файлу артефакта, розмір і checksum, коли показано.

Використовуйте download action збірки лише після завершення artifact finalization. Пакет завантаження може містити ISO та пов’язані докази. Якщо download повертає Failed to create download package, not found або іншу JSON-помилку:

1. переконайтеся, що ви signed in як власник збірки;
2. відкрийте точну збірку, а не старішу conversation card;
3. перевірте, що artifact finalization завершена і ISO у списку;
4. повторіть один раз;
5. повідомте build ID, мітку часу, показані build/test/finalization states і точний текст помилки.

Не перезбирайте лише через помилку власності або пакування; це може знищити корисний діагностичний стан і зайняти ще один build slot.

6. Перевірте ISO у призначеному контексті

Завантаження в VM OpenFactory перевіряє лише налаштоване віртуальне середовище. Для installable desktop також перевірте шлях installer на одноразовому диску. Для фізичного розгортання окремо перевірте firmware mode, storage, graphics, networking, suspend, input devices, updates і recovery на репрезентативному обладнанні.

Типові шляхи відновлення

Наступні кроки

• Understanding Recipes
• Recipe Schema
• Custom Assertions
• VNC Console