fix(build): stop the version stamp from breaking every Portainer deploy (#235)
`COPY .git ./.git`, added in #233, fails with `"/.git": not found` in Portainer's build context, so every stack deploy died before anything else ran. This is the exact outcome #233 set out to prevent. That issue states that a version stamp must never be the thing that stops a deploy, and the resolution code honours it — every unreadable-.git path returns "unknown" and warns. The guard was simply in the wrong layer: COPY fails at image-build time, long before any of that code executes. Graceful degradation in the application buys nothing once the Dockerfile has refused to build. The assumption came from the local build context, where there is no .dockerignore and .git is therefore present. It was checked with a local `docker build`, which passed, and never against the only environment that actually deploys. Verified properly this time, by building from `git archive HEAD` — a context containing exactly the tracked files and no history, which is what a clean checkout gives. That build now succeeds and stamps `commit: "unknown"` with a real `builtAt`. The failing case is reproduced and fixed rather than reasoned about. `commit` will read "unknown" wherever Portainer builds. `builtAt` is still real, and is the half that matters most: Portainer already reports which commit it cloned, but cannot tell you whether the running container is that build. A build time can, and a stale one is exactly what the QA incident earlier today would have shown. Locally nothing changes — writeBuildInfo reads ../.git directly and still resolves a real commit. Sourcing the real commit inside a Portainer build needs a different mechanism, and #235 records the three candidates rather than guessing at a fourth. Closes #235
This commit is contained in:
+12
-11
@@ -10,18 +10,19 @@ 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 deliberately no `COPY .git` here. It was tried in #233 and broke
|
||||
# every Portainer deploy with `"/.git": not found` — Portainer's build context
|
||||
# does not contain the repository history, whatever a local `docker build`
|
||||
# suggests. That was the version stamp becoming the thing that stopped a
|
||||
# deploy, which is the one outcome it must never be (#235).
|
||||
#
|
||||
# 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.
|
||||
# The consequence is that `commit` reads "unknown" in any environment Portainer
|
||||
# builds. `builtAt` is still real, and is the half that matters most here:
|
||||
# Portainer already reports which commit it cloned, but it cannot tell you
|
||||
# whether the running container is actually that build. A build time can.
|
||||
#
|
||||
# writeBuildInfo runs against the compiled output, so it has to follow tsc, and
|
||||
# it warns rather than fails when it finds no .git.
|
||||
RUN npm run build && node dist/writeBuildInfo.js
|
||||
|
||||
FROM node:20-bookworm-slim
|
||||
|
||||
Reference in New Issue
Block a user