Say that a build from a linked worktree needs the version passed in (closes #111)

A plain `docker build .` from a checkout whose `.git` is a file (a linked worktree, or a repository checked out as a submodule) stops at the version check of the canonical `Dockerfile` example: that file points to a git directory outside the build context, so `git describe` prints nothing. The check is right to refuse an empty version; what was missing is what to do. `prompts/REPO_POLICIES.md` and both checklists now say such a build is given its version with `--build-arg VERSION=...`, as `script/docker` and `script/cibuild` already do. The check itself is unchanged. Model: opus-5-5
2026-10-06 06:33:19 +02:00
parent 6aac45857a
commit 01954b6946
4 changed files with 28 additions and 4 deletions
@@ -281,6 +281,12 @@ style conventions are in separate documents:
      `.git` and the version still comes out empty, `dev` or `unknown`. A plain
      `docker build .` with no build arguments must succeed; a Dockerfile that
      refuses an empty build argument drops that refusal and keeps the argument.
+      A checkout whose `.git` is a file (a linked worktree, or a repository
+      checked out as a submodule) is the exception: that file points to a git
+      directory outside the build context, so the build cannot read the version
+      and a plain `docker build .` fails; pass the version with
+      `--build-arg VERSION=...`, as `script/docker` and `script/cibuild` already
+      do.

 - Every repo should have a Gitea Actions workflow (`.gitea/workflows/`) that
  runs `script/cibuild` on push, and checks out the repo as its only other step,