Dreistufiges Dockerfile mit standalone-Ausgabe; im Laufzeitabbild liegen weder Quelltext noch Bauwerkzeuge, und es läuft unter einem eigenen Benutzer. Die Migrationen erledigt ein eigener Einmaldienst aus der Bau-Stufe. Der Versuch, nur die Prisma-CLI ins Laufzeitabbild zu kopieren, scheiterte an ihren transitiven Modulen; sie alle mitzunehmen hätte das Abbild aufgebläht. Der Dienst läuft vor der App und muss sauber durchlaufen. Zwei Stellen mussten faul werden, weil Next beim Bauen Seitendaten sammelt und dabei Module lädt, die es zur Bauzeit noch ohne Umgebungsvariablen gibt: - Der Prisma-Client entsteht erst beim ersten Zugriff, über einen Proxy. - Die Auth.js-Konfiguration wird als Funktion übergeben. Ebenso liest prisma.config.ts die URL über process.env statt über env(), das beim Bauen ohne Datenbank abbricht. Dazu backup.sh, update.sh mit Rückrollpfad und scripts/release.sh. Der Dump wurde nachweislich in eine Wegwerf-Datenbank zurückgespielt und stimmt zeilengenau mit dem Original überein. Alle Skripte sind shellcheck-sauber. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
18 lines
545 B
TypeScript
18 lines
545 B
TypeScript
import 'dotenv/config'
|
|
import { defineConfig } from 'prisma/config'
|
|
|
|
export default defineConfig({
|
|
schema: 'prisma/schema.prisma',
|
|
migrations: {
|
|
path: 'prisma/migrations',
|
|
seed: 'tsx prisma/seed.ts',
|
|
},
|
|
datasource: {
|
|
// Bewusst über process.env statt über den env()-Helfer: "prisma generate"
|
|
// läuft auch beim Bauen des Abbilds, wo es noch gar keine Datenbank gibt.
|
|
// env() bricht dort ab. Fehlt die URL für migrate oder studio, meldet
|
|
// Prisma das selbst.
|
|
url: process.env.DATABASE_URL ?? '',
|
|
},
|
|
})
|