# syntax=docker/dockerfile:1

# Base-Image per Digest gepinnt (node:22-alpine, Multi-Arch-Index vom
# 2026-09-23): ein Rebuild zieht nie ungeprueft ein neues Image. Ein Update
# ist ein bewusster Commit mit neuem Digest, ermittelt per
#   docker buildx imagetools inspect node:22-alpine
FROM node:22-alpine@sha256:0a7108bf6c7bf5de370ffb1a3ed6be93d405b43ff159f681a8d18c0e2bc2e402 AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npx prisma generate
# Qualitaets-Gate: ein Image entsteht nur, wenn Lint, Typecheck und
# Unit-Tests gruen sind. eslint laeuft hier ohne --fix (anders als
# `npm run lint`), damit ein Verstoss den Build abbricht statt still
# korrigiert zu werden. Die e2e-Tests brauchen eine Datenbank und laufen
# deshalb nicht im Image-Build.
RUN npx eslint "{src,test}/**/*.ts" && npm run typecheck && npm test -- --ci
RUN npm run build

FROM node:22-alpine@sha256:0a7108bf6c7bf5de370ffb1a3ed6be93d405b43ff159f681a8d18c0e2bc2e402 AS runtime
ENV NODE_ENV=production
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/generated ./generated
# schema.prisma, migrations/ und prisma.config.ts: noetig fuer den
# initContainer `migrate` (siehe Kommentar ueber CMD unten).
# seed.ts selbst wird NICHT zur Laufzeit ausgefuehrt -
# `npm run build` kompiliert es vorab zu dist/seed.js (siehe
# tsconfig.seed.json), das schon in ./dist enthalten ist. Frueher lief
# `ts-node prisma/seed.ts` direkt im Container: der TypeScript-Compiler
# braucht dafuer deutlich mehr Heap als das 512Mi-Pod-Limit hergibt und
# fuehrte zu sporadischen OOM-Crashes beim Start.
COPY --from=builder /app/prisma ./prisma
COPY --from=builder /app/prisma.config.ts ./prisma.config.ts
# 3001: HTTP der api-Rolle. 3002: /health der worker-Rolle.
EXPOSE 3001 3002
USER node
# Migration und Seed laufen nicht mehr hier, sondern als initContainer im
# Pod (deploy/k8s/components/backend-roles): `migrate` in api und worker
# (`node node_modules/prisma/build/index.js migrate deploy`, idempotent mit
# DB-seitigem Advisory-Lock), `seed` nur in der api (`node dist/seed.js`,
# idempotent per Unique-Constraint auf User.email). Scheitert die Migration,
# startet der neue Pod nicht und der alte laeuft weiter. Der Hauptprozess
# startet ohne Prisma-CLI; worker und Jobs ueberschreiben das Kommando
# (dist/worker.js, dist/cli.js <job>), die Rolle waehlt APICORE_ROLE.
# Dieses Image darf darum nur zusammen mit components/backend-roles live
# gehen (Runbook Schritt 3). Fehlt APICORE_ROLE, bricht der Start in
# Produktion absichtlich ab. APICORE_ROLE nicht von Hand in ein Deployment
# ohne die initContainer setzen: dann liefe keine Migration.
CMD ["node", "dist/main.js"]