Meine Dockerfile-Änderungen scheinen nicht angewendet zu werden

Sie haben ein Dockerfile in Ihrem Repo, Sie haben es bearbeitet, aber der Build, den Lizard ausführt, entspricht nicht dem, was Sie geschrieben haben.

Was das bedeutet

Die Plattform hat entschieden, dass das Dockerfile Ihres Repos unvollständig war, und mit lizardpack stattdessen eines für Sie neu erzeugt, anstatt Ihres unverändert zu verwenden.

Warum das passieren kann

Diese Prüfung läuft nur für Services mit GitHub-Quelle. Uploads (lizard up) verwenden ein Dockerfile im Root-Verzeichnis immer so, wie es geschrieben ist.

Bei GitHub-Quelle behandelt Lizard ein Dockerfile im Root-Verzeichnis als unvollständig, wenn beides zutrifft:

• es enthält ein COPY von build, dist, out, .next oder public ohne abschließenden Schrägstrich, etwa COPY dist /usr/share/nginx/html;
• es enthält keine RUN-Zeile, die mit npm, yarn, pnpm, bun, pip, pip3, bundle, cargo, go build, mvn oder gradle beginnt.

Lizard geht davon aus, dass diese Artefakte außerhalb des Images gebaut wurden, und lizardpack erzeugt ein Ersatz-Dockerfile, das den fehlenden Build-Schritt enthält.

Zwei weitere Einstellungen umgehen ebenfalls das Dockerfile im Root-Verzeichnis Ihres Repos. Ist dockerfilePath gesetzt, verwendet Lizard diese Datei unverändert. Ohne diese Einstellung sorgt ein gesetztes buildCommand oder startCommand dafür, dass Lizard aus diesen Befehlen ein Dockerfile erzeugt.

Mögliche Lösungen

Einen echten Build-Schritt hinzufügen

Wenn Sie möchten, dass Ihr Dockerfile unverändert verwendet wird, geben Sie ihm einen tatsächlichen Build-Schritt, anstatt vorab gebaute Ausgaben zu kopieren:

RUN npm ci && npm run build

Oder die unveränderte Verwendung erzwingen

Setzen Sie dockerfilePath. Es hat beim Image-Build Vorrang vor Build- und Start-Befehlen, aber ein gesetztes startCommand ersetzt zur Laufzeit trotzdem das CMD Ihres Dockerfiles. Setzen Sie daher beide im selben Update zurück. Ein leerer Wert setzt ein Feld zurück:

lizard service set api --set buildCommand= --set startCommand= --set dockerfilePath=Dockerfile

Siehe auch

• Build-Pipeline — die vollständige Reihenfolge der Build-Entscheidungen.
• Referenz zur Build-Konfiguration
• Ein minimaler FastAPI-Container — ein vollständiges Python-Dockerfile und wann Sie stattdessen Ihr eigenes mitbringen sollten, statt den Source-Build zu verwenden.

Das Ändern dieser Build-Felder kann einen Build starten. Prüfen Sie lizard events, bevor Sie ein weiteres redeploy senden, um zu vermeiden, einen zweiten Build zu starten.

Aktualisiert 9. Oktober 2026