kyuno/batchCooking
1
0
Fork 0
Code Issues 5 Pull requests Projects Releases Packages Wiki Activity Actions 1

fix(api): seed reference data (diets/allergies) on container start

Browse source 
Found on http://batch.dev.kyuno.fr/: GET /reference/diets and
/reference/allergies both returned [] — onboarding's "régime
alimentaire" step and the profile's food-preferences tab had nothing to
show. Cause: the Docker image's CMD only ran `prisma migrate deploy`
(schema), never the seed that populates Diet/Category/Allergy.

Adds src/scripts/seed-runtime.ts — a runtime-only seed entry point
(distinct from prisma/seed.ts, the dev-time one wired to `prisma db
seed`/`prisma migrate reset` via tsx importing from ../src, which isn't
shipped in the runtime image). This one lives under src/ so tsc compiles
it into dist/ alongside everything else, and runs via plain `node`,
reusing the same idempotent seedReferenceData() (upserts by unique name)
already used by prisma/seed.ts and test-support/reset-db.ts.

Dockerfile CMD now runs it between migrate deploy and starting the
server — safe on every container start/restart, confirmed idempotent
locally (no duplicates, no error on a second run against an
already-seeded database).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Nicolas 2026-08-18 00:04:14 +02:00
parent 77b9d14f7e
commit fff8c0da26
2 changed files with 32 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
apps/api/Dockerfile
View file

@ -42,6 +42,8 @@ COPY --from=build /repo/apps/web/dist ./apps/web/dist
WORKDIR /repo/apps/api WORKDIR /repo/apps/api
EXPOSE 3000 EXPOSE 3000
# Applies pending migrations before starting — keeps the review environment's # Applies pending migrations, then seeds the reference data (Diet/Category/
# schema in sync automatically, no manual step needed. # Allergy — see src/scripts/seed-runtime.ts) before starting. Both steps are
CMD ["sh", "-c", "node_modules/.bin/prisma migrate deploy && node dist/server.js"] # safe to repeat on every container start: migrate deploy only applies
# pending migrations, and the seed upserts by unique name.
CMD ["sh", "-c", "node_modules/.bin/prisma migrate deploy && node dist/scripts/seed-runtime.js && node dist/server.js"]

27
apps/api/src/scripts/seed-runtime.ts Normal file
View file

@ -0,0 +1,27 @@
import { prisma } from "../db/prisma.js";
import { seedReferenceData } from "../db/reference-seed-data.js";
/**
* Runtime seed entry point for the production Docker image — run via
* `node dist/scripts/seed-runtime.js` in apps/api/Dockerfile's CMD, after
* `prisma migrate deploy` and before starting the server.
*
* Deliberately separate from `prisma/seed.ts` (the dev-time entry point
* wired to `prisma db seed`/`prisma migrate reset`): that one imports
* `seedReferenceData` from `../src/db/...` and runs via `tsx`, but the
* runtime image only ships compiled `dist` output, not `src` (see the
* Dockerfile) — this lives under `src/` instead, so `tsc` compiles it
* alongside everything else, and it runs under plain `node`, no tsx
* needed at runtime.
*
* Safe to run on every container start: `seedReferenceData` upserts by
* each row's unique name, so re-running it against a database that
* already has this data is a no-op.
*/
seedReferenceData(prisma)
.then(() => prisma.$disconnect())
.catch(async (err) => {
console.error(err);
await prisma.$disconnect();
process.exit(1);
});