Seu primeiro build

Este passo a passo cria, valida, constrói e inspeciona uma imagem personalizada. Uma receita validada é uma verificação de configuração, não prova de que o ISO foi construído ou de que todo comportamento solicitado passou em teste de VM.

Antes de começar

Faça sign-in para que a conversa e o build permaneçam ligados à sua conta.
Comece com um sistema operacional e um conjunto pequeno de pacotes ou serviços.
Decida qual evidência provaria que o pedido foi atendido. Presença de pacote, estado de serviço, porta em escuta e comportamento de GUI são asserções diferentes.

Na primeira execução, evite credenciais e URLs de repositório privado no chat. Adicione segredos depois pelo fluxo de credenciais suportado, em vez de embuti-los na imagem.

1. Declare o resultado e suas verificações

Exemplo:


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.

Exclusões específicas ajudam a distinguir uma imagem mínima intencional de um pedido que o planejador simplesmente não capturou.

2. Inspecione a prévia da receita

Verifique pelo menos:

base_image corresponde à distribuição e release solicitadas;
pacotes solicitados aparecem em os.packages ou são fornecidos por um feature explícito;
usuários, grupos, serviços, rede, instalador e escolhas de desktop correspondem ao pedido;
scenarios contêm as verificações que você realmente precisa;
nenhum pacote, desktop, instalador, credencial ou repositório externo não solicitado foi introduzido.

Peça alterações na mesma conversa. Pedidos de follow-up são aplicados à receita ativa. Quando Validate Recipe é usado, o backend preserva o pedido substantivo anterior do chat e bloqueia a receita se requisitos explícitos ainda estiverem faltando; a frase de controle gerada não pode apagar a intenção da conversa.

A validação ainda pode falhar em pacote indisponível, indisponibilidade upstream, falha de build específica da distro ou comportamento sem teste. Leia a prévia como um contrato proposto.

3. Inicie o build uma vez

Selecione Start Build na prévia validada. Um clique bem-sucedido cria um ID de build. Guarde esse ID ao reportar um problema; é mais confiável do que apenas uma porcentagem ou captura de tela.

O painel de build pode mostrar estados como queued, planning, configured, building, finalizing, completed, failed ou cancelled. Um build enfileirado pode aguardar capacidade de worker ou recuperação de inicialização. Uma porcentagem exibida é projeção de progresso, não prazo; algumas etapas de empacotamento e filesystem levam muito mais tempo que outras.

Você pode continuar acompanhando o build no painel ao vivo mesmo se sair da view original do chat. Recarregar deve reconectar pelo estado persistido do build e pelo stream de eventos. Não clique Start Build repetidamente a menos que a UI reporte que nenhum ID de build foi criado ou que o build anterior atingiu estado terminal.

4. Separe conclusão da imagem da conclusão dos testes

Uma imagem pode terminar antes da verificação em VM selecionada atingir estado terminal. Leia ambos:

build status: se um artefato durável foi montado e finalizado;
test status: not_run, running, passed, failed ou error;
certification status, quando presente: resultado da política de evidência configurada, não uma certificação universal de segurança ou hardware.

Abra os detalhes do teste. Confirme que cada asserção solicitada rodou contra o guest esperado e inspecione falhas ou verificações ignoradas. Um teste de boot aprovado não prova que um aplicativo abre; um registro de pacote não prova que seu serviço está saudável.

5. Inspecione e baixe o artefato

Antes de baixar, compare a receita final e evidências de pacotes/testes com o pedido. Registre ID de build, nome do arquivo do artefato, tamanho e checksum quando exibidos.

Use a ação de download do build somente após a finalização do artefato concluir. O pacote de download pode conter o ISO e evidências relacionadas. Se o download retornar Failed to create download package, not found ou outro erro JSON:

confirme que está autenticado como proprietário do build;
reabra o build exato, não um card de conversa mais antigo;
verifique que a finalização do artefato está completa e o ISO está listado;
tente uma vez;
reporte ID de build, timestamp, estados exibidos de build/teste/finalização e texto exato do erro.

Não refaça o build apenas para contornar erro de propriedade ou empacotamento; isso pode descartar estado diagnóstico útil e consumir outro slot de build.

6. Teste o ISO no contexto pretendido

Inicializar na VM do OpenFactory verifica apenas o ambiente virtual configurado. Para desktop instalável, teste também o caminho do instalador em disco descartável. Para implantação física, teste separadamente modo de firmware, storage, gráficos, rede, suspend, dispositivos de entrada, updates e recovery em hardware representativo.

Caminhos comuns de recuperação

Sintoma	Ação
Receita valida mas omite um pedido	Não construa; declare o requisito faltante explicitamente e valide de novo
Build está enfileirado	Mantenha o ID de build e verifique status de fila/recuperação; evite starts duplicados
Progresso parece inalterado	Inspecione o estágio atual e atividade recente nos logs antes de declarar travado
Build falha	Leia o primeiro erro causal, não só o resumo final; revise ou tente de novo só depois de entender a causa
Testes falham	Distinga defeito de produto, defeito de asserção, problema de boot do guest e erro de infraestrutura
Download ausente ou proibido	Confirme sessão do proprietário, estado de finalização e ID de build exato antes de reconstruir