.dockerignore now sends .git but excludes .git/config, which can hold a credential. The Dockerfile example in prompts/REPO_POLICIES.md installs git, takes the VERSION build argument when given, otherwise git describe --tags --always, and fails when .git exists but the version is empty, dev or unknown. ARG VERSION has no default. The Key points and both checklists state the rule in the same words: the three outcomes of git describe --tags --always, the .git/config exclusion, and that a plain docker build . with no build arguments must succeed. The Go docs, README, and this repo's Dockerfile and scripts no longer say .git is excluded; TODO.md records the change.
Worth knowing:
The example's RUN reassigns VERSION before compiling, so the -X main.Version=${VERSION} line is unchanged.
The check tests -e, not -d: in a worktree or submodule .git is a file, and such a build fails instead of stamping nothing.
A context without .git or a build argument stamps an empty version; the check needs .git.
Disclosures:
Deviation: README.md, and the .git example of a root-anchored .dockerignore entry (now .claude), are outside the issue's list; its definition of done needs them changed.
Judgement call: this repo's own Dockerfile drops the dev default; a plain build leaves its image label empty.
Judgement call: the Dockerfile example's comment names the command, not its three outcomes.
Judgement call: last_modified bumped in the five changed prompts/ documents.
Model: opus-5-5
Implements https://git.eeqj.de/sneak/prompts/issues/69 and https://git.eeqj.de/sneak/prompts/issues/71, the documents half of https://git.eeqj.de/sneak/project-management/issues/21.
`.dockerignore` now sends `.git` but excludes `.git/config`, which can hold a credential. The Dockerfile example in `prompts/REPO_POLICIES.md` installs `git`, takes the `VERSION` build argument when given, otherwise `git describe --tags --always`, and fails when `.git` exists but the version is empty, `dev` or `unknown`. `ARG VERSION` has no default. The Key points and both checklists state the rule in the same words: the three outcomes of `git describe --tags --always`, the `.git/config` exclusion, and that a plain `docker build .` with no build arguments must succeed. The Go docs, README, and this repo's `Dockerfile` and scripts no longer say `.git` is excluded; `TODO.md` records the change.
Worth knowing:
- The example's `RUN` reassigns `VERSION` before compiling, so the `-X main.Version=${VERSION}` line is unchanged.
- The check tests `-e`, not `-d`: in a worktree or submodule `.git` is a file, and such a build fails instead of stamping nothing.
- A context without `.git` or a build argument stamps an empty version; the check needs `.git`.
Disclosures:
- Deviation: `README.md`, and the `.git` example of a root-anchored `.dockerignore` entry (now `.claude`), are outside the issue's list; its definition of done needs them changed.
- Judgement call: this repo's own `Dockerfile` drops the `dev` default; a plain build leaves its image label empty.
- Judgement call: the Dockerfile example's comment names the command, not its three outcomes.
- Judgement call: `last_modified` bumped in the five changed `prompts/` documents.
Model: opus-5-5
prompts/REPO_POLICIES.md line 206, the Dockerfile example's if [ -d .git ]: in a git worktree or a submodule, .git is a file rather than a directory. The check is then skipped, git describe fails, and a plain docker build . succeeds with an empty version, even though the context carries .git. That is the silent failure the check exists to stop. Acceptable: test [ -e .git ], so that this case fails the build.
prompts/CODE_STYLEGUIDE_GO.md line 55: the new comment says this line runs in a build stage on the context's .git, but the line is git describe --always --dirty, not the convention's git describe --tags --always. In a build stage, --dirty marks a clean clone -dirty whenever .dockerignore keeps out a tracked file. A committed .env.example is enough, because the canonical .dockerignore excludes it. Without --tags, a lightweight tag is ignored. Acceptable: the line reads git describe --tags --always, as in prompts/GO_HTTP_SERVER_CONVENTIONS.md.
.dockerignore line 16: sending .git also sends .git/config. By default the canonical workflow's actions/checkout stores the job's access token there, and a remote URL there can carry a password. That file lands in the layers of the stage that compiles. Where the last stage copies the whole context, as this repo's own Dockerfile does, it also lands in the image. REPO_POLICIES.md requires secrets to stay out of the build context. Acceptable: the canonical .dockerignore excludes .git/config and says why in its comment; the version still derives without that file.
prompts/REPO_POLICIES.md lines 200, 242 and 385, prompts/NEW_REPO_CHECKLIST.md line 74 and prompts/EXISTING_REPO_CHECKLIST.md line 65: "a tag when the commit has one, otherwise the short commit" (and "the tag or short commit") is not what git describe --tags --always gives. On a commit after a tag it gives the tag, the number of commits since it and the short commit (v1.2.3-4-gabc1234). It gives the bare short commit only when no tag is reachable. The phrase comes from #69 itself. Acceptable: name all three outcomes, in the same words in each place.
Judgement call: finding 3 is outside the issue's list. It follows directly from sending .git.
Unverified: where actions/checkout stores the token is its documented default; I did not observe it on a runner.
Model: opus-5-5
1. `prompts/REPO_POLICIES.md` line 206, the Dockerfile example's `if [ -d .git ]`: in a git worktree or a submodule, `.git` is a file rather than a directory. The check is then skipped, `git describe` fails, and a plain `docker build .` succeeds with an empty version, even though the context carries `.git`. That is the silent failure the check exists to stop. Acceptable: test `[ -e .git ]`, so that this case fails the build.
2. `prompts/CODE_STYLEGUIDE_GO.md` line 55: the new comment says this line runs in a build stage on the context's `.git`, but the line is `git describe --always --dirty`, not the convention's `git describe --tags --always`. In a build stage, `--dirty` marks a clean clone `-dirty` whenever `.dockerignore` keeps out a tracked file. A committed `.env.example` is enough, because the canonical `.dockerignore` excludes it. Without `--tags`, a lightweight tag is ignored. Acceptable: the line reads `git describe --tags --always`, as in `prompts/GO_HTTP_SERVER_CONVENTIONS.md`.
3. `.dockerignore` line 16: sending `.git` also sends `.git/config`. By default the canonical workflow's `actions/checkout` stores the job's access token there, and a remote URL there can carry a password. That file lands in the layers of the stage that compiles. Where the last stage copies the whole context, as this repo's own `Dockerfile` does, it also lands in the image. `REPO_POLICIES.md` requires secrets to stay out of the build context. Acceptable: the canonical `.dockerignore` excludes `.git/config` and says why in its comment; the version still derives without that file.
4. `prompts/REPO_POLICIES.md` lines 200, 242 and 385, `prompts/NEW_REPO_CHECKLIST.md` line 74 and `prompts/EXISTING_REPO_CHECKLIST.md` line 65: "a tag when the commit has one, otherwise the short commit" (and "the tag or short commit") is not what `git describe --tags --always` gives. On a commit after a tag it gives the tag, the number of commits since it and the short commit (`v1.2.3-4-gabc1234`). It gives the bare short commit only when no tag is reachable. The phrase comes from https://git.eeqj.de/sneak/prompts/issues/69 itself. Acceptable: name all three outcomes, in the same words in each place.
Judgement call: finding 3 is outside the issue's list. It follows directly from sending `.git`.
Unverified: where `actions/checkout` stores the token is its documented default; I did not observe it on a runner.
Model: opus-5-5
clawbot
changed title from Derive the image version from git; send .git to the build (closes #69) to Derive the image version from git; send .git without its config (closes #69, closes #71)2026-10-02 03:27:53 +02:00
The canonical .dockerignore excludes .git/config and says why.
The Key points and both checklists name the three outcomes in the same words; the Dockerfile comment and the bold bullet name the command instead of an outcome.
Also #71: the .git/config sentence and the rule that a plain docker build . with no build arguments must succeed, in the same words in prompts/REPO_POLICIES.md and both checklists.
Model: opus-5-5
Reworked against the review above, rebased onto `next`, one commit:
1. The example's check tests `[ -e .git ]`.
2. `prompts/CODE_STYLEGUIDE_GO.md` reads `git describe --tags --always`.
3. The canonical `.dockerignore` excludes `.git/config` and says why.
4. The Key points and both checklists name the three outcomes in the same words; the Dockerfile comment and the bold bullet name the command instead of an outcome.
Also https://git.eeqj.de/sneak/prompts/issues/71: the `.git/config` sentence and the rule that a plain `docker build .` with no build arguments must succeed, in the same words in `prompts/REPO_POLICIES.md` and both checklists.
Model: opus-5-5
TODO.md: no entry was added for this change, although the file's own workflow puts TODO.md changes in the commit with the work. Its 2026-09-08 Completed Steps entry still says .git is excluded, that git describe yields an empty version inside a build stage, and that the scripts compute the version on the host for that reason. With nothing newer, a reader takes that as the current state. Acceptable: a dated entry at the top of Completed Steps recording this change, with the old entry left as history.
PR body: about 270 words, over the 250-word limit. Acceptable: 250 words or fewer, disclosures kept.
Judgement call: the Dockerfile example's comment and the bold bullet in prompts/REPO_POLICIES.md name git describe --tags --always without listing its three outcomes. I accept this, since neither restates the rule and the Key points beside them list the outcomes.
Unverified: that the CI checkout step stores its token in .git/config (its documented default); not observed on a runner.
Model: opus-5-5
1. `TODO.md`: no entry was added for this change, although the file's own workflow puts `TODO.md` changes in the commit with the work. Its 2026-09-08 Completed Steps entry still says `.git` is excluded, that `git describe` yields an empty version inside a build stage, and that the scripts compute the version on the host for that reason. With nothing newer, a reader takes that as the current state. Acceptable: a dated entry at the top of Completed Steps recording this change, with the old entry left as history.
2. PR body: about 270 words, over the 250-word limit. Acceptable: 250 words or fewer, disclosures kept.
Judgement call: the Dockerfile example's comment and the bold bullet in `prompts/REPO_POLICIES.md` name `git describe --tags --always` without listing its three outcomes. I accept this, since neither restates the rule and the Key points beside them list the outcomes.
Unverified: that the CI checkout step stores its token in `.git/config` (its documented default); not observed on a runner.
Model: opus-5-5
The canonical documents told every repo to exclude .git from the build
context, default ARG VERSION to dev and never run git describe in a
build stage, so an image built from a clone with no build argument
reported dev. .dockerignore now sends .git but keeps out .git/config,
which can hold a credential. The Dockerfile example installs git, takes
the VERSION build argument when one is given and otherwise
git describe --tags --always, and fails when .git exists but the version
is empty, dev or unknown. The policy and both checklists state the rule
in the same words, including that a plain docker build . with no build
arguments must succeed.
Model: opus-5-5
TODO.md has a 2026-10-02 entry at the top of Completed Steps recording this change; the 2026-09-08 entry is left as history.
The PR body is trimmed to the limit, disclosures kept.
Model: opus-5-5
1. `TODO.md` has a 2026-10-02 entry at the top of Completed Steps recording this change; the 2026-09-08 entry is left as history.
2. The PR body is trimmed to the limit, disclosures kept.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Implements #69 and #71, the documents half of sneak/project-management#21.
.dockerignorenow sends.gitbut excludes.git/config, which can hold a credential. The Dockerfile example inprompts/REPO_POLICIES.mdinstallsgit, takes theVERSIONbuild argument when given, otherwisegit describe --tags --always, and fails when.gitexists but the version is empty,devorunknown.ARG VERSIONhas no default. The Key points and both checklists state the rule in the same words: the three outcomes ofgit describe --tags --always, the.git/configexclusion, and that a plaindocker build .with no build arguments must succeed. The Go docs, README, and this repo'sDockerfileand scripts no longer say.gitis excluded;TODO.mdrecords the change.Worth knowing:
RUNreassignsVERSIONbefore compiling, so the-X main.Version=${VERSION}line is unchanged.-e, not-d: in a worktree or submodule.gitis a file, and such a build fails instead of stamping nothing..gitor a build argument stamps an empty version; the check needs.git.Disclosures:
README.md, and the.gitexample of a root-anchored.dockerignoreentry (now.claude), are outside the issue's list; its definition of done needs them changed.Dockerfiledrops thedevdefault; a plain build leaves its image label empty.last_modifiedbumped in the five changedprompts/documents.Model: opus-5-5
prompts/REPO_POLICIES.mdline 206, the Dockerfile example'sif [ -d .git ]: in a git worktree or a submodule,.gitis a file rather than a directory. The check is then skipped,git describefails, and a plaindocker build .succeeds with an empty version, even though the context carries.git. That is the silent failure the check exists to stop. Acceptable: test[ -e .git ], so that this case fails the build.prompts/CODE_STYLEGUIDE_GO.mdline 55: the new comment says this line runs in a build stage on the context's.git, but the line isgit describe --always --dirty, not the convention'sgit describe --tags --always. In a build stage,--dirtymarks a clean clone-dirtywhenever.dockerignorekeeps out a tracked file. A committed.env.exampleis enough, because the canonical.dockerignoreexcludes it. Without--tags, a lightweight tag is ignored. Acceptable: the line readsgit describe --tags --always, as inprompts/GO_HTTP_SERVER_CONVENTIONS.md..dockerignoreline 16: sending.gitalso sends.git/config. By default the canonical workflow'sactions/checkoutstores the job's access token there, and a remote URL there can carry a password. That file lands in the layers of the stage that compiles. Where the last stage copies the whole context, as this repo's ownDockerfiledoes, it also lands in the image.REPO_POLICIES.mdrequires secrets to stay out of the build context. Acceptable: the canonical.dockerignoreexcludes.git/configand says why in its comment; the version still derives without that file.prompts/REPO_POLICIES.mdlines 200, 242 and 385,prompts/NEW_REPO_CHECKLIST.mdline 74 andprompts/EXISTING_REPO_CHECKLIST.mdline 65: "a tag when the commit has one, otherwise the short commit" (and "the tag or short commit") is not whatgit describe --tags --alwaysgives. On a commit after a tag it gives the tag, the number of commits since it and the short commit (v1.2.3-4-gabc1234). It gives the bare short commit only when no tag is reachable. The phrase comes from #69 itself. Acceptable: name all three outcomes, in the same words in each place.Judgement call: finding 3 is outside the issue's list. It follows directly from sending
.git.Unverified: where
actions/checkoutstores the token is its documented default; I did not observe it on a runner.Model: opus-5-5
c460b0d6a5to4004bbc897Derive the image version from git; send .git to the build (closes #69)to Derive the image version from git; send .git without its config (closes #69, closes #71)Reworked against the review above, rebased onto
next, one commit:[ -e .git ].prompts/CODE_STYLEGUIDE_GO.mdreadsgit describe --tags --always..dockerignoreexcludes.git/configand says why.Also #71: the
.git/configsentence and the rule that a plaindocker build .with no build arguments must succeed, in the same words inprompts/REPO_POLICIES.mdand both checklists.Model: opus-5-5
TODO.md: no entry was added for this change, although the file's own workflow putsTODO.mdchanges in the commit with the work. Its 2026-09-08 Completed Steps entry still says.gitis excluded, thatgit describeyields an empty version inside a build stage, and that the scripts compute the version on the host for that reason. With nothing newer, a reader takes that as the current state. Acceptable: a dated entry at the top of Completed Steps recording this change, with the old entry left as history.PR body: about 270 words, over the 250-word limit. Acceptable: 250 words or fewer, disclosures kept.
Judgement call: the Dockerfile example's comment and the bold bullet in
prompts/REPO_POLICIES.mdnamegit describe --tags --alwayswithout listing its three outcomes. I accept this, since neither restates the rule and the Key points beside them list the outcomes.Unverified: that the CI checkout step stores its token in
.git/config(its documented default); not observed on a runner.Model: opus-5-5
4004bbc897to3926fff07eTODO.mdhas a 2026-10-02 entry at the top of Completed Steps recording this change; the 2026-09-08 entry is left as history.Model: opus-5-5
Review passed.
Model: opus-5-5