Entender recetas

Un BuildRecipe es la especificación normalizada que OpenFactory envía al pipeline de imágenes. El chat puede ayudar a redactarla, pero la receta, las instantáneas de origen, los archivos generados y la evidencia de prueba son lo que define una compilación.

El modelo mental

La receta canónica tiene cuatro capas principales:

1. Identidad y objetivo: nombre, descripción, imagen base e intención de hardware.
2. Sistema operativo: features, paquetes, servicios, usuarios, seguridad, escritorio, instalador, adjuntos y scripts de arranque bajo os.
3. Verificación: uno o más escenarios con pruebas integradas y aserciones personalizadas.
4. Intención de entrega: destinos de publicación solicitados y ajustes de entrega opcionales.

{
  "name": "debian-web-check",
  "display_name": "Debian Web Check",
  "description": "Small Debian image with explicit smoke tests.",
  "base_image": "debian-trixie",
  "hardware": {
    "platform": "pc",
    "architecture": "x86_64",
    "min_cpu_cores": 2,
    "min_memory_gb": 4,
    "min_storage_gb": 16,
    "nic_count": 1
  },
  "os": {
    "features": ["ssh"],
    "packages": ["curl"],
    "services": [
      {
        "name": "ssh",
        "enabled": true,
        "config": {"port": 22, "disable_password_auth": true}
      }
    ],
    "security": {
      "hardening_level": "standard",
      "audit_logging": true
    }
  },
  "scenarios": [
    {
      "id": "primary-smoke",
      "name": "Primary image smoke test",
      "enabled": true,
      "tests": ["boot", "login", "packages"]
    }
  ],
  "publish_to": ["local"]
}

Usa snake_case. Las integraciones nuevas no deben enviar formas legacy como baseImage, features de nivel superior ni startupScripts.

Tres comprobaciones, tres respuestas distintas

Validación de esquema

La validación responde: «¿Los datos reconocidos tienen una forma aceptable?» No prueba que existan paquetes ni que el comportamiento funcione. Algunos campos desconocidos se ignoran por compatibilidad, así que un éxito de validación puede omitir aún una solicitud importante.

Compara siempre la receta normalizada devuelta con el chat y los requisitos originales. Un escritorio, aplicación, instalador, adjunto o prueba faltante es un defecto de receta aunque la validación diga valid.

Evidencia de compilación

Una compilación exitosa responde: «¿El pipeline produjo un artefacto?» No prueba que cada feature prevista llegara a la imagen. Inspecciona el inventario de paquetes, la procedencia de fuentes, advertencias y evidencia por etapa de compilación.

Verificación en guest

Las pruebas en guest responden preguntas estrechas de runtime: si la VM arrancó, un servicio está activo, un puerto escucha, un archivo tiene el contenido esperado o una aplicación se lanzó. Una aserción superada respalda solo el comportamiento que realmente observó.

Los ajustes de seguridad son intención

Los valores aceptados de hardening_level son minimal, standard y strict, pero esas etiquetas no son perfiles de cumplimiento portables. Los generadores de destino pueden interpretarlas de forma distinta. Si necesitas un benchmark, selecciona el benchmark aplicable exacto y conserva resultados por control; no infieras conformidad CIS desde strict.

Del mismo modo, disk_encryption, audit_logging, SELinux, fail2ban, Secure Boot, dm-verity y ajustes del instalador requieren pruebas de artefacto y runtime acordes.

Chat y propiedad de la receta

Cuando validas o editas una receta creada en chat, la conversación existente sigue formando parte del contexto de autoría. La validación debe refinar la receta actual, no sustituirla en silencio por un valor por defecto genérico. Aun así, la receta normalizada es el último punto de control antes de compilar.

Para cada requisito material:

• localiza el campo normalizado correspondiente;
• confirma su valor y alcance de destino;
• añade una aserción donde sea posible prueba en runtime; y
• conserva el trabajo solo de despliegue como advertencia explícita en lugar de fingir que ocurrió durante la compilación de imagen.

Lista de revisión

• ¿La imagen base y la arquitectura son correctas?
• ¿Están presentes todas las features de escritorio y aplicación solicitadas?
• ¿Las fuentes externas están fijadas y licenciadas para el uso previsto?
• ¿Faltan secretos en campos y scripts guardados de la receta?
• ¿El instalador está configurado y probado en un disco desechable si se solicitó?
• ¿Los escenarios prueban los criterios de aceptación reales?
• ¿Se señalan requisitos no admitidos o solo en tiempo de despliegue?

Consulta Esquema de recetas para la referencia de campos y Tu primera compilación para el flujo de compilación y descarga.