fix: prisma migrate now runs at container startup + dotenv optional
Deploy to VPS / deploy (push) Has been cancelled
Deploy to VPS / deploy (push) Has been cancelled
Two related fixes for the deploy pipeline so DB schema changes never again leave the site half-deployed. PRISMA CONFIG (prisma.config.ts) - "import 'dotenv/config'" was hard-required, but dotenv isn't installed in the production runtime image (env vars come from docker-compose). - Wrapped in try/catch so it loads .env locally and silently no-ops in the container — `prisma migrate deploy` works in both environments. DOCKERFILE - Copies node_modules/prisma + prisma.config.ts to the runner stage so the CLI is available at runtime, not just at build. - New CMD runs `prisma migrate deploy` before booting the server. Idempotent — already-applied migrations are skipped. If the DB is unreachable, the container exits and docker-compose retries. - This means: from now on, `git pull && docker compose up -d --build app` is the entire deploy. No more "did you remember to run migrations?". DEFENSIVE TRY/CATCH (applications/[slug]/page.tsx) - prisma.application.findUnique and prisma.globalNode.findMany now have try/catch with logged errors. A transient DB hiccup or missing Application slug now degrades gracefully (renders "not found" or empty cases wall) instead of triggering a 500 Internal Server Error. DEPLOY (David, this is the recovery sequence on the VPS) cd /opt/flux-srl git pull docker compose up -d --build app # The container will run pending migrations on its own. # No need to run `prisma migrate deploy` manually anymore.
This commit is contained in:
+9
-2
@@ -54,10 +54,14 @@ COPY --from=builder /app/public ./public
|
||||
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
|
||||
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static
|
||||
|
||||
# Copy Prisma schema + generated client (needed for migrations at runtime)
|
||||
# Copy Prisma schema + generated client + CLI binaries (the CLI is needed
|
||||
# at runtime so the entrypoint can run `prisma migrate deploy` before the
|
||||
# server boots — avoids the "table does not exist" race after schema changes)
|
||||
COPY --from=builder /app/prisma ./prisma
|
||||
COPY --from=builder /app/prisma.config.ts ./prisma.config.ts
|
||||
COPY --from=builder /app/node_modules/.prisma ./node_modules/.prisma
|
||||
COPY --from=builder /app/node_modules/@prisma ./node_modules/@prisma
|
||||
COPY --from=builder /app/node_modules/prisma ./node_modules/prisma
|
||||
|
||||
# Copy sharp binary explicitly — Next.js standalone trace usually picks it
|
||||
# up, but the @img/sharp-linuxmusl-x64 prebuilt is platform-conditional and
|
||||
@@ -75,4 +79,7 @@ EXPOSE 3000
|
||||
ENV PORT=3000
|
||||
ENV HOSTNAME="0.0.0.0"
|
||||
|
||||
CMD ["node", "server.js"]
|
||||
# Run pending migrations on startup, then boot the Next.js server.
|
||||
# `migrate deploy` is idempotent — it skips already-applied migrations.
|
||||
# If the DB is unreachable the container exits and docker-compose retries.
|
||||
CMD ["sh", "-c", "node ./node_modules/prisma/build/index.js migrate deploy && node server.js"]
|
||||
|
||||
Reference in New Issue
Block a user