Build
Sobald eine Template-Definition bereit ist, verwenden SieTemplate.build(...), um sie zu bauen. Der Build akzeptiert einen Template-Namen sowie optionale Build-Einstellungen wie CPU, Arbeitsspeicher, Tags, Cache-Verhalten und einen Build-Log-Callback.
Template.buildInBackground(...) / Template.build_in_background(...) und prüfen Sie später den Build-Status.
Namen
Jeder Build benötigt einen Template-Namen. Halten Sie Namen für eine logische Template-Familie stabil, zum Beispiel:my-python-templateagent-runtime-basesandbox-webapp
Tags & Versionierung
Mit Tags können Sie Builds für das Release-Management kennzeichnen, ohne den zugrunde liegenden Template-Namen zu ändern. Typische Muster sind:- semantische Versionen wie
v1.0.0 - Promotion-Labels wie
stagingoderproduction - bewegliche Kanäle wie
latest
Logging
Build-Logs helfen Ihnen, den Provisionierungsfortschritt zu überprüfen und Fehler zu diagnostizieren. In JavaScript und TypeScript übergeben SieonBuildLogs an Template.build(...). Das SDK exportiert außerdem defaultBuildLogger(...) für einen standardmäßigen Konsolen-Logger.
Template.getBuildStatus(...) / Template.get_build_status(...), um den Status abzufragen und Log-Einträge später abzurufen.
Fehlerbehandlung
Template-Builds können aus mehreren häufigen Gründen fehlschlagen:- ungültige Anmeldedaten für eine private Registry
- Fehler bei der Paketinstallation innerhalb von
runCmd(...)/run_cmd(...) - ein Startbefehl, der unerwartet beendet wird
- ein Ready-Befehl, der nie erfolgreich ist
- CPU- und Arbeitsspeichereinstellungen, die die Plattformgrenzen nicht erfüllen
- prüfen Sie zuerst die Build-Logs
- validieren Sie das Template-Quell-Image oder Dockerfile
- führen Sie den Build mit deaktiviertem Cache erneut aus, wenn Sie eine veraltete Schicht vermuten
- reduzieren Sie das Template auf die kleinste fehlgeschlagene Befehlssequenz
building, waiting, ready und error bereit.