[BaaRai]

Follow-up to 1ed154e ("fix: build the image locally instead of pulling a third-party namespace"). That commit got two things only partly done.

The two gaps

1. A fresh clone cannot build the image. docker-compose.yml builds artex:local from the local Dockerfile, but the Dockerfile still did COPY dist/${TARGETARCH}/artex /app/artex. /dist/ is in .gitignore, so a fresh clone has no binary there, and docker compose up -d --build (what install.sh runs) fails at that COPY. install.sh only printed a warning and then built anyway. (.dockerignore does not exclude dist/, so the build worked for anyone who had built the binary by hand first.)
2. The Docker update path could ship stale code. update.sh runs git pull and then docker compose build artex, but nothing rebuilt dist/<arch>/artex. The new image wrapped whatever old binary was left in dist/.

There was also a loose end: compose passed ARTEX_VERSION as a build arg, but the Dockerfile never declared it.

The change

• Dockerfile: two build stages ahead of the unchanged runtime stage. They run the release workflow's own commands:
  • web (node:22-bookworm-slim): npm ci and npm run build:static, matching the release frontend job.
  • build (golang:1.26-bookworm): ./build.sh --target linux/$TARGETARCH with ARTEX_SKIP_FRONTEND=1 ARTEX_COMPRESS=0, matching the release binaries job. This keeps the same -tags embedui -trimpath -ldflags "-s -w -buildid= -X main.version=..." flags because it is the same script.
  • ARG ARTEX_VERSION=dev is now declared and passed to build.sh as ARTEX_BUILD_VERSION. The compose build arg now actually sets main.version, so it stays in compose.
  • The runtime stage copies /out/artex from the build stage instead of dist/.
  • Both build stages use --platform=$BUILDPLATFORM and cross-compile, so multi-arch builds only emulate the runtime layers, the same as before.
• install.sh: removed the dist/ warning, which no longer applies.
• update.sh: the menu text said "pull new image and rebuild"; it now says it rebuilds from this checkout. Gap 2 needed no other change: once the binary is built inside the image, docker compose build artex after git pull compiles the pulled source. There is no dist/ step left to keep in sync.

docker-compose.yml, README.md and release.yml are unchanged. The release docker job is off by default (DOCKERHUB_ENABLED). It still downloads binaries into dist/, which this Dockerfile now ignores, so that job builds from source too. Those download steps are now unused but harmless.

Relation to #127

#127 (draft, currently conflicting with main) also adds frontend and Go build stages, as part of a larger rewrite: checksum-verified tool downloads, a pinned Node and Playwright, and a GHCR publish job. The build-stage part overlaps. This PR keeps to that part only and is written against main as it stands. It reuses build.sh rather than inlining a go build, so the image and the release binaries share one build definition. If #127 lands later, its Dockerfile supersedes this one.

Verification

Run from a worktree of this branch (Kali WSL for Go and Docker, Windows for npm):

Check	Result
POSTGRES_PASSWORD=dummy docker compose -f docker-compose.yml config	parses, exit 0; build arg ARTEX_VERSION: dev
bash -n install.sh / bash -n update.sh	exit 0 / exit 0
go build ./...	exit 0
web stage commands (npm ci, then NEXT_EXPORT=1 next build)	exit 0, web/out produced (run on Windows with Node 26, not node:22)
build stage RUN line, run verbatim with TARGETARCH=amd64 ARTEX_VERSION=v9.9.9-test and that web/out copied into server/webui/dist	exit 0; static x86-64 ELF; go version -m shows -tags=embedui; the binary contains 9.9.9-test (the v is stripped by build.sh, as for releases); artex -h runs
same with TARGETARCH=arm64	exit 0; static aarch64 ELF

Not verified

• No docker build was run. The Docker daemon available to me (in WSL) cannot reach Docker Hub, so it cannot pull docker/dockerfile:1, node:22-bookworm-slim, golang:1.26-bookworm or python:3.12-slim-bookworm. Docker Desktop on the Windows side was not running. Even docker build --check stopped at resolving the base images. What is untested is the Dockerfile wiring itself: the COPY paths between stages, $BUILDPLATFORM/$TARGETARCH handling, and npm ci under node:22 (including the web package's prepare: husky script, which also runs in CI where web/ has no .git). Please run docker compose build artex on a fresh clone before merging.
• No multi-arch buildx run.
• The full Go test suite was not run as part of this change.

This PR does not touch any live deployment: no containers were started, stopped or rebuilt, and no running stack was changed.

🤖 Generated with Claude Code