The Go styleguide and the HTTP server conventions no longer pass the build architecture in at build time; their examples read runtime.GOARCH at run time (#67, for sneak/project-management#19).
The canonical .dockerignore sends .git without its config, and the Dockerfile example derives the image version from git describe --tags --always unless a VERSION build argument is given, failing when .git is present but no version comes out. The policy and both checklists state the rule in the same words, including that a plain docker build . must succeed (#70, for sneak/project-management#21). This reverses the earlier rule that excluded .git and forbade git describe in a build stage.
Model: opus-5-5
On `next`:
- The Go styleguide and the HTTP server conventions no longer pass the build architecture in at build time; their examples read `runtime.GOARCH` at run time (https://git.eeqj.de/sneak/prompts/pulls/67, for https://git.eeqj.de/sneak/project-management/issues/19).
- The canonical `.dockerignore` sends `.git` without its `config`, and the Dockerfile example derives the image version from `git describe --tags --always` unless a `VERSION` build argument is given, failing when `.git` is present but no version comes out. The policy and both checklists state the rule in the same words, including that a plain `docker build .` must succeed (https://git.eeqj.de/sneak/prompts/pulls/70, for https://git.eeqj.de/sneak/project-management/issues/21). This reverses the earlier rule that excluded `.git` and forbade `git describe` in a build stage.
Model: opus-5-5
The Go styleguide and the HTTP server conventions no longer pass the
build architecture in through the Makefile. The Buildarch variable,
globals field and BUILDARCH Makefile lines are removed from every
example; the styleguide example prints runtime.GOARCH, and the
logger's Identify logs "arch", runtime.GOARCH. The styleguide item
gains one sentence saying so.
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
clawbot
changed title from next → main: read the architecture at run time to next → main: architecture at run time, version from git2026-10-02 04:38:22 +02:00
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.
On
next:runtime.GOARCHat run time (#67, for sneak/project-management#19)..dockerignoresends.gitwithout itsconfig, and the Dockerfile example derives the image version fromgit describe --tags --alwaysunless aVERSIONbuild argument is given, failing when.gitis present but no version comes out. The policy and both checklists state the rule in the same words, including that a plaindocker build .must succeed (#70, for sneak/project-management#21). This reverses the earlier rule that excluded.gitand forbadegit describein a build stage.Model: opus-5-5
next → main: read the architecture at run timeto next → main: architecture at run time, version from gitView command line instructions
Checkout
From your project repository, check out a new branch and test the changes.