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

Lizard verwendet ein Dockerfile aus dem Repo im lizardpack-Autoerkennungspfad nur dann unverändert, wenn es einen echten Build-Schritt hat — eine Zeile RUN <package-manager>. Ein Dockerfile, das nur vorab gebaute Artefakte kopiert (COPY dist/, build/, out/, .next/, public/) und keinen Schritt RUN enthält, wird als unvollständig behandelt, in der Annahme, dass diese Artefakte außerhalb des Images gebaut wurden. In diesem Fall erzeugt lizardpack ein Ersatz-Dockerfile, das den fehlenden Build-Schritt enthält.

Das gilt nur auf dem lizardpack-Autoerkennungspfad. Wenn buildCommand oder startCommand für den Service gesetzt ist, erzeugt Lizard stattdessen aus diesen Befehlen ein Dockerfile und berücksichtigt das Dockerfile Ihres Repos überhaupt nicht.

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

Entfernen Sie Build- und Start-Overrides und setzen Sie dann im selben Update dockerfilePath. Overrides haben Vorrang vor dem Dateipfad:

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

Siehe auch

• Build-Pipeline — die vollständige Reihenfolge der Build-Entscheidungen.
• Referenz zur Build-Konfiguration
• Beliebige Python-App auf Lizard deployen — wann Sie lizardpack das Dockerfile schreiben lassen sollten und wann Sie Ihr eigenes mitbringen.

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.