Read --version from Go build info

[mbyczkowski]

Why

certstrap --version comes from var release = "1.3.0" in certstrap.go. Someone has to bump it by hand before every tag. If they forget, go install github.com/square/certstrap@v1.4.0 installs a binary that reports 1.3.0. Master already reports 1.3.0. The release workflow works around this with -ldflags -X, but go install and source builds don't get that override.

What

--version now prints the module version that Go stamps into the binary from git, the same way certigo does since square/certigo#372. Tagging a release is the only step needed to set the version.

How

• version.go reads debug.ReadBuildInfo().Main.Version and removes the leading v. -ldflags "-X main.release=..." still overrides it, for example in builds from a source tarball. With neither, it prints (devel).
• The release workflow no longer passes -X. Each of the five builds now reads the version from the binary with go version -m, and fails if:
  • a tag build doesn't report exactly that tag, or
  • any build reports (devel) or +dirty.
• The linux/amd64 build also checks that --version matches the module version.
• dist/ is now in .gitignore, so a leftover release build can't mark the next one dirty.

What --version prints, from builds with Go 1.24.11:

Build	--version
go install …@v1.4.0, or a build at tag v1.4.0	1.4.0
Shallow checkout of the tag, as in the release workflow	1.4.0
Commit after a tag	1.4.1-0.20261005185508-578ddd1a9789
Uncommitted or untracked files	…+dirty
-buildvcs=false, go run, or no .git directory	(devel)

Risk

The Dockerfile builds with -buildvcs=false, so the Docker image now prints (devel) instead of the stale 1.3.0. No workflow builds or publishes that image. Tags must be valid semver with a v prefix (v1.4.0, v1.4.0-rc.1), or the release build fails the version check instead of publishing a mislabeled binary.

Testing

• Unit tests cover the override, tag, prerelease, pseudo-version, +dirty and (devel) cases.
• I ran the release build step locally on a clone of this branch:
  • At a local v1.4.0 tag, it passed and reported v1.4.0.
  • With a mismatched tag, or with an untracked file, it failed with the expected error.
• The release workflow runs on this PR because the PR changes it.

🤖 Generated with Claude Code