ugyanez AI-val javítva:
"Korábban írtam, hogy hozok példát, és közben felmerült pár kérdés is, amire most tudok válaszolni.
A CI folyamatban történik a validáció, mégpedig a CI környezetben futó CICrelay-ben. Gyakorlatilag egy rekurzív séma-validáció zajlik. Minden WASM modul (amelyek a végrehajtók) rendelkezik saját API-val, ehhez tartozik egy séma-leírás, valamint egy YAML alapú metaadat-kísérő fájl, amely hivatkozik a konkrét séma definíciójára. Ebből egyértelműen meghatározható, hogy egy adott paraméter validációjáért mely séma a felelős, és a rendszer ezt ténylegesen ellenőrzi még azelőtt, hogy az IaC a CD folyamatba kerülne.
A CRD-k validációját többféleképpen is el lehet képzelni, de számomra egy CRD akkor „létezik”, ha a fejlesztő bizonyította, hogy helyesen működik, és megfelel a tesztelők és a minőségbiztosítók követelményeinek. Ide tartozik többek között:
- dokumentáció (program, API),
- az API-k teljes séma-leírásai (beleértve a telepítési paramétereket),
- unit tesztek megfelelő lefedettséggel,
- API-szintű mock/contract tesztek,
- integrációs tesztek,
- a fenti tesztekre mutációs tesztek,
- valamint egy kezdeti SonarQube elemzés.
Ha valóban komolyan vesszük a minőséget, akkor ezek még kiegészülnek:
- nem-funkcionális tesztekkel (teljesítmény, skálázás, biztonság, auditlog stb.),
- üzemeltethetőségi / observability tesztekkel (logok, metrikák, health checkek).
És akkor még nem beszéltem a kriptográfiai bizonyíthatóságról, pedig az alapvető elvárás lenne minden komponensnél.
A kérdés tehát az: a Crossplane által biztosított CRD-k esetében kijelenthető-e, hogy ezeknek a követelményeknek megfelelnek?
Hozzáteszem, nem használtam hosszú ideig a Crossplane-t. Korábban nagyjából 2–3 hetet foglalkoztam vele, amikor kipróbáltam (talán a Talos 1.3 vagy 1.4 környékén, de erre már nem esküdnék). Végül akkor nem győzött meg, ezért nem vittem tovább."
szerintem így olvashatóbb, és nem jön le belőle azonnal, hogy egy 2 mondatos promptból generálta az AI