A plain docker build . stamped dev: .dockerignore left out .git and the Dockerfile defaulted VERSION to dev.
.dockerignore is the canonical one from sneak/prompts plus this repo's own entries: .git is sent, .git/config is not.
The builder installs git. Given no build arguments, it stamps git describe --tags --always as the version, and the commit and date from git; it fails if the context carries .git but yields no version. Values passed by script/docker and script/cibuild take precedence.
The Dockerfile no longer refuses an empty CHECK_EPOCH, so the plain build succeeds; the scripts still pass one. Dockerfile.lint keeps its refusal.
script/version now prints git describe --tags --always --dirty, so every entrypoint stamps the same value for a clean commit: untagged builds report the short commit instead of dev-<sha>, and a tag keeps its leading v.
vaultik version counts the short commit and <tag>-<N>-g<sha> (with or without -dirty) as development builds, so those keep the development-build notice; a plain tag stays a release.
Disclosures:
Judgement call: a goreleaser release of tag v1.0.0 still reports 1.0.0; make and docker report v1.0.0.
Judgement call: commit and date are derived too, so a plain build's version output has no unknown.
Deviation: script/docker claimed to be the canonical copy but differs on purpose (CHECK_EPOCH, COMMIT, COMMIT_DATE); edited minimally, its header now says how.
The canonical .dockerignore keeps test/insecure-integration-test.key out of the build; no test reads it.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/vaultik/issues/211.
A plain `docker build .` stamped `dev`: `.dockerignore` left out `.git` and the `Dockerfile` defaulted `VERSION` to `dev`.
- `.dockerignore` is the canonical one from `sneak/prompts` plus this repo's own entries: `.git` is sent, `.git/config` is not.
- The builder installs `git`. Given no build arguments, it stamps `git describe --tags --always` as the version, and the commit and date from git; it fails if the context carries `.git` but yields no version. Values passed by `script/docker` and `script/cibuild` take precedence.
- The `Dockerfile` no longer refuses an empty `CHECK_EPOCH`, so the plain build succeeds; the scripts still pass one. `Dockerfile.lint` keeps its refusal.
- `script/version` now prints `git describe --tags --always --dirty`, so every entrypoint stamps the same value for a clean commit: untagged builds report the short commit instead of `dev-<sha>`, and a tag keeps its leading `v`.
- `vaultik version` counts the short commit and `<tag>-<N>-g<sha>` (with or without `-dirty`) as development builds, so those keep the development-build notice; a plain tag stays a release.
Disclosures:
- Judgement call: a goreleaser release of tag `v1.0.0` still reports `1.0.0`; make and docker report `v1.0.0`.
- Judgement call: commit and date are derived too, so a plain build's version output has no `unknown`.
- Deviation: `script/docker` claimed to be the canonical copy but differs on purpose (`CHECK_EPOCH`, `COMMIT`, `COMMIT_DATE`); edited minimally, its header now says how.
- The canonical `.dockerignore` keeps `test/insecure-integration-test.key` out of the build; no test reads it.
Model: opus-5-5
internal/globals/globals.go (IsDevVersion, used by internal/cli/version.go): a make build or plain docker build . of an untagged commit now prints vaultik 877eb2f with no development-build notice, and once a tag exists every later commit prints v1.0.0-3-g877eb2f, which leads with a release number, also with no notice. The notice exists so that a build that is not a release says so (TestVersionCommandFlagsDevelopmentBuild, and the 2026-08-09 TODO.md entry that introduced IsDevVersion for exactly this case); this change brings back the gap it closed and documents it instead. Acceptable: IsDevVersion also counts the bare short commit and the <tag>-<N>-g<sha> form (with or without -dirty) as development builds, with test cases for both next to a plain tag (v1.0.0, 1.0.0) that stays a release; the IsDevVersion comment and the README say so; the judgement-call disclosure goes.
script/version header: "the image build, which otherwise runs the same git describe itself" is not accurate, since the build runs it without --dirty. Acceptable: say so, as the README does.
Model: opus-5-5
- `internal/globals/globals.go` (`IsDevVersion`, used by `internal/cli/version.go`): a make build or plain `docker build .` of an untagged commit now prints `vaultik 877eb2f` with no development-build notice, and once a tag exists every later commit prints `v1.0.0-3-g877eb2f`, which leads with a release number, also with no notice. The notice exists so that a build that is not a release says so (`TestVersionCommandFlagsDevelopmentBuild`, and the 2026-08-09 `TODO.md` entry that introduced `IsDevVersion` for exactly this case); this change brings back the gap it closed and documents it instead. Acceptable: `IsDevVersion` also counts the bare short commit and the `<tag>-<N>-g<sha>` form (with or without `-dirty`) as development builds, with test cases for both next to a plain tag (`v1.0.0`, `1.0.0`) that stays a release; the `IsDevVersion` comment and the README say so; the judgement-call disclosure goes.
- `script/version` header: "the image build, which otherwise runs the same `git describe` itself" is not accurate, since the build runs it without `--dirty`. Acceptable: say so, as the README does.
Model: opus-5-5
internal/globals/globals.go (IsDevVersion): v1.0.0-dirty, which script/version gives a make or script/docker build of a tagged commit with uncommitted changes, still counts as a release, so that build prints no development-build notice. The README says a modified checkout of a tag is not that tag and that only a plain tag is a release; the code disagrees, and no test covers the case. Acceptable: any version ending in -dirty counts as a development build, TestIsDevVersion has v1.0.0-dirty as one, and the IsDevVersion comment says so.
Model: opus-5-5
- `internal/globals/globals.go` (`IsDevVersion`): `v1.0.0-dirty`, which `script/version` gives a `make` or `script/docker` build of a tagged commit with uncommitted changes, still counts as a release, so that build prints no development-build notice. The README says a modified checkout of a tag is not that tag and that only a plain tag is a release; the code disagrees, and no test covers the case. Acceptable: any version ending in `-dirty` counts as a development build, `TestIsDevVersion` has `v1.0.0-dirty` as one, and the `IsDevVersion` comment says so.
Model: opus-5-5
A plain `docker build .` stamped `dev`: `.dockerignore` left out `.git`
and the Dockerfile defaulted VERSION to `dev`. `.dockerignore` now
sends `.git` without `.git/config`. Given no build arguments, the
builder stamps `git describe --tags --always` and the commit and date
from git, and fails if `.git` is present but yields no version. The
empty CHECK_EPOCH refusal is gone so the plain build succeeds.
`script/version` now prints `git describe --tags --always --dirty`, so
make, the scripts and a plain build agree. `vaultik version` treats
the short commit, tag-N-gHASH forms and any version ending in `-dirty`
as development builds, so they keep the development-build notice.
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.
Fixes #211.
A plain
docker build .stampeddev:.dockerignoreleft out.gitand theDockerfiledefaultedVERSIONtodev..dockerignoreis the canonical one fromsneak/promptsplus this repo's own entries:.gitis sent,.git/configis not.git. Given no build arguments, it stampsgit describe --tags --alwaysas the version, and the commit and date from git; it fails if the context carries.gitbut yields no version. Values passed byscript/dockerandscript/cibuildtake precedence.Dockerfileno longer refuses an emptyCHECK_EPOCH, so the plain build succeeds; the scripts still pass one.Dockerfile.lintkeeps its refusal.script/versionnow printsgit describe --tags --always --dirty, so every entrypoint stamps the same value for a clean commit: untagged builds report the short commit instead ofdev-<sha>, and a tag keeps its leadingv.vaultik versioncounts the short commit and<tag>-<N>-g<sha>(with or without-dirty) as development builds, so those keep the development-build notice; a plain tag stays a release.Disclosures:
v1.0.0still reports1.0.0; make and docker reportv1.0.0.unknown.script/dockerclaimed to be the canonical copy but differs on purpose (CHECK_EPOCH,COMMIT,COMMIT_DATE); edited minimally, its header now says how..dockerignorekeepstest/insecure-integration-test.keyout of the build; no test reads it.Model: opus-5-5
internal/globals/globals.go(IsDevVersion, used byinternal/cli/version.go): a make build or plaindocker build .of an untagged commit now printsvaultik 877eb2fwith no development-build notice, and once a tag exists every later commit printsv1.0.0-3-g877eb2f, which leads with a release number, also with no notice. The notice exists so that a build that is not a release says so (TestVersionCommandFlagsDevelopmentBuild, and the 2026-08-09TODO.mdentry that introducedIsDevVersionfor exactly this case); this change brings back the gap it closed and documents it instead. Acceptable:IsDevVersionalso counts the bare short commit and the<tag>-<N>-g<sha>form (with or without-dirty) as development builds, with test cases for both next to a plain tag (v1.0.0,1.0.0) that stays a release; theIsDevVersioncomment and the README say so; the judgement-call disclosure goes.script/versionheader: "the image build, which otherwise runs the samegit describeitself" is not accurate, since the build runs it without--dirty. Acceptable: say so, as the README does.Model: opus-5-5
877eb2f755to51a5d71b8ainternal/globals/globals.go(IsDevVersion):v1.0.0-dirty, whichscript/versiongives amakeorscript/dockerbuild of a tagged commit with uncommitted changes, still counts as a release, so that build prints no development-build notice. The README says a modified checkout of a tag is not that tag and that only a plain tag is a release; the code disagrees, and no test covers the case. Acceptable: any version ending in-dirtycounts as a development build,TestIsDevVersionhasv1.0.0-dirtyas one, and theIsDevVersioncomment says so.Model: opus-5-5
51a5d71b8atoca07a78990Review passed.
Model: opus-5-5