bermudalamb
44328d0b5c
There was no way to tell which build an environment was running. That is not hypothetical: minutes after #232 merged, `npm run backfill:images` in QA failed with `tsx: not found` because the container was still serving the pre-merge image, and the only thing that revealed it was npm echoing the old script line. Had the change been anywhere other than a package.json script, the container would have looked healthy while running the wrong code.
The header now reads something like `a5076cc · built 29 Aug 20:36`. The commit answers "is this the code I expect"; the build time answers "did my redeploy actually rebuild", which is a different question and the one that would have caught the case above.
The commit is read out of `.git` directly rather than by shelling out, because node:20-bookworm-slim has no git binary and adding an apt layer so the image can print seven characters is a poor trade. `.git` is copied into the build stage only — verified absent from the final image — so no repository history reaches a deployed container.
Resolution is pure and separately tested across every shape that actually occurs: a detached HEAD holding the object name, which is what a checkout of a ref produces; a symbolic HEAD followed to a loose ref file; the same followed to packed-refs, which is what a fresh clone commonly has; peeled `^` tag lines ignored so an annotated tag cannot yield the wrong commit; and every failure path returning `unknown`. That last part is the one that matters most — this runs during a Docker build, and a version stamp must never be the thing that stops a deploy.
Served from a gated /api/admin/version rather than folded into /api/config. That endpoint is public, and a commit hash there would tell any storefront visitor exactly which revision of a public repository is deployed. An integration test asserts the gate and asserts the public config does not carry it, because the boundary is the whole point rather than an implementation detail.
Verified in the built image rather than argued: the stamp inside it reads a5076cc, matching `git rev-parse --short HEAD`, and a running container serves it from /api/admin/version while /api/config returns only what it did before.
Backend: 296 unit, 263 integration, tsc clean, lint unchanged at six pre-existing warnings. Frontend builds clean with its two pre-existing warnings untouched.
Closes #233
45 lines
2.0 KiB
Docker
Executable File
45 lines
2.0 KiB
Docker
Executable File
FROM node:20-bookworm-slim AS frontend-build
|
|
WORKDIR /app/frontend
|
|
COPY frontend/package.json ./
|
|
RUN npm install
|
|
COPY frontend/ ./
|
|
RUN npm run build
|
|
|
|
FROM node:20-bookworm-slim AS backend-build
|
|
WORKDIR /app/backend
|
|
COPY backend/package.json ./
|
|
RUN npm install
|
|
COPY backend/ ./
|
|
# Only this stage ever sees .git, and the final image below copies just `dist`,
|
|
# so no repository history reaches the deployed container. The build reads the
|
|
# commit out of it directly rather than shelling out to git, because this base
|
|
# image has no git binary and adding an apt layer so the image can print seven
|
|
# characters is a poor trade. See #233.
|
|
#
|
|
# There is no .dockerignore, so .git is in the build context here and in
|
|
# Portainer, which clones the repository before building.
|
|
COPY .git ./.git
|
|
# writeBuildInfo runs against the compiled output, so it has to follow tsc. It
|
|
# warns rather than fails when .git is unreadable: a deploy must never be
|
|
# stopped by the thing whose only job is to say which deploy it is.
|
|
RUN npm run build && node dist/writeBuildInfo.js
|
|
|
|
FROM node:20-bookworm-slim
|
|
WORKDIR /app
|
|
COPY --from=backend-build /app/backend/package.json ./
|
|
RUN npm install --omit=dev
|
|
COPY --from=backend-build /app/backend/dist ./dist
|
|
COPY --from=backend-build /app/backend/migrate.js ./migrate.js
|
|
COPY --from=backend-build /app/backend/migrations ./migrations
|
|
COPY --from=frontend-build /app/frontend/dist ./public
|
|
ENV NODE_ENV=production
|
|
EXPOSE 3000
|
|
# Migrations run before the app serves, so deployed code can never be ahead of
|
|
# the database schema. Previously this was a separate, manual
|
|
# `docker exec ... node migrate.js up` that was easy to forget — and forgetting
|
|
# it meant every item query referenced tables that did not exist yet, which
|
|
# surfaced as an empty storefront rather than an error.
|
|
#
|
|
# `&&` matters: migrate.js exits non-zero on failure, so a bad migration stops
|
|
# the container instead of letting it serve against a half-migrated schema.
|
|
CMD ["sh", "-c", "node migrate.js up && node dist/server.js"] |