Forstå oppskrifter
En BuildRecipe er den normaliserte spesifikasjonen OpenFactory sender til image-pipelinen. Chat kan hjelpe med å skrive den, men oppskriften, kilde-snapshots, genererte filer og testbevis definerer et build.
Mental modell
Den kanoniske oppskriften har fire hovedlag:
- Identitet og mål: navn, beskrivelse, base image og hardware-intensjon.
- Operativsystem: features, pakker, tjenester, brukere, sikkerhet, desktop, installer, attachments og startup scripts under
os. - Verifikasjon: ett eller flere scenarier med innebygde tester og egendefinerte assertions.
- Leveringsintensjon: forespurte publiseringsdestinasjoner og valgfrie leveringsinnstillinger.
{
"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"]
}Bruk snake_case. Nye integrasjoner bør ikke sende legacy-former som baseImage, top-level features eller startupScripts.
Tre kontroller, tre ulike svar
Skjemavalidering
Validering svarer: «Har de gjenkjente dataene en akseptabel form?» Den beviser verken at pakker finnes eller at oppførsel fungerer. Noen ukjente felt ignoreres av hensyn til kompatibilitet, så vellykket validering kan likevel utelate en viktig forespørsel.
Sammenlign alltid den returnerte normaliserte oppskriften med opprinnelig chat og krav. Manglende desktop, applikasjon, installer, attachment eller test er en oppskriftsfeil selv om valideringen sier valid.
Buildbevis
Et vellykket build svarer: «Produserte pipelinen et artefakt?» Det beviser ikke at hver tiltenkte feature kom med i imaget. Gå gjennom pakkelager, kilde-proveniens, advarsler og bevis fra build-trinn.
Gjestverifikasjon
Gjesttester besvarer smale runtime-spørsmål: om VM-en startet, en tjeneste er aktiv, en port lytter, en fil har forventet innhold, eller en applikasjon startet. En bestått assertion støtter bare oppførselen som faktisk ble observert.
Sikkerhetsinnstillinger er intensjon
De aksepterte verdiene for hardening_level er minimal, standard og strict, men etikettene er ikke portable compliance-profiler. Målgeneratorer kan tolke dem ulikt. Hvis du trenger et benchmark, velg det nøyaktig relevante benchmarket og behold resultater per control; ikke utled CIS-samsvar fra strict.
På samme måte krever disk_encryption, audit_logging, SELinux, fail2ban, Secure Boot, dm-verity og installer-innstillinger matchende artefakt- og runtime-tester.
Chat og oppskriftseierskap
Når du validerer eller redigerer en chat-forfattet oppskrift, forblir den eksisterende samtalen en del av authoring-konteksten. Validering bør finjustere den nåværende oppskriften, ikke stille erstatte den med en generisk standard. Likevel er den normaliserte oppskriften siste kontrollpunkt før build.
For hvert vesentlige krav:
- finn det tilsvarende normaliserte feltet;
- bekreft verdi og målomfang;
- legg til en assertion der runtime-bevis er mulig; og
- bevar deployment-only arbeid som eksplisitt advarsel i stedet for å late som om det skjedde under image-build.
Gjennomgangssjekkliste
- Er base image og arkitektur korrekte?
- Er alle forespurte desktop- og applikasjonsfeatures til stede?
- Er eksterne kilder festet og lisensiert for tiltenkt bruk?
- Mangler hemmeligheter i lagrede oppskriftsfelt og scripts?
- Er installer konfigurert og testet på engangs-disk hvis det ble forespurt?
- Tester scenariene de faktiske akseptkriteriene?
- Er krav som ikke støttes eller gjelder ved deployment nevnt?
Se Oppskriftsskjema for feltreferanse og Din første build for build- og nedlastingsworkflow.