Read --version from Go build info

[mbyczkowski]

Why

certigo --version prints a string that is hard-coded in cli/cli.go. Someone has to edit it before each release, and the edit is easy to miss. It was wrong in 3 of the last 6 releases:

Release	--version prints
v1.15.0	1.14.1
v1.17.0	1.16.0
v1.18.0	1.17.1

Go already records the module version in every binary it builds. go version -m on the v1.18.0 release binary shows v1.18.0, but the binary prints 1.17.1.

What

--version now prints the version that Go records at build time, so a release needs no version edit. Builds without git metadata can still set the version with -ldflags -X.

How

appVersion() returns the first of these that is set:

1. The -X override: -ldflags "-X github.com/square/certigo/cli.version=1.18.1".
2. debug.ReadBuildInfo().Main.Version, minus the leading v. This keeps today's format: 1.18.1, not v1.18.1.
3. (devel).

What each kind of build prints:

Build	--version
Release workflow on tag v1.18.1	1.18.1
go install github.com/square/certigo@v1.18.1	1.18.1
go build at an untagged commit	1.18.1-0.20260923190547-3992878d286c
go build with uncommitted changes	the same, plus +dirty
No git metadata: source tarball, go run, -buildvcs=false	(devel)

• Go 1.24 and later stamp the version from git tags. The go line in go.mod is 1.25.0, so every toolchain that can build certigo does this.
• --help-man puts the version in the man page header, so the man page follows the same rules.

Risk

Low for go install users and release downloads. They get the right version with no other change.

Homebrew builds from the GitHub source tarball, which has no git metadata. Until the formula passes the version in, Homebrew builds print (devel). Today they print the stale 1.17.1. See Bigger picture for the formula fix.

Testing

All builds used go1.27.1 on darwin/arm64:

• Scratch clone with a local-only v1.18.1 tag on this commit: go build -o certigo . && ./certigo --version prints 1.18.1.
• Shallow clone plus one tag fetch, as actions/checkout does on a tag push: git clone --depth=1 --no-tags, then git fetch --depth=1 origin +refs/tags/v1.18.1:refs/tags/v1.18.1. The build prints 1.18.1.
• git archive tarball of that tag, built with ./build: prints (devel).
• Same tarball, built with GOFLAGS=-ldflags=-X=github.com/square/certigo/cli.version=1.18.1 ./build: prints 1.18.1, and man/certigo.1 starts with .TH certigo 1 1.18.1.
• go install github.com/square/certigo@3992878d286c8ef8b073fddba1bad3656deaaea2 prints 1.18.1-0.20260923190547-3992878d286c.
• go version -m on the v1.18.0 release asset shows mod github.com/square/certigo v1.18.0. The release workflow already builds with the tag in place.

Bigger picture

• Releases no longer need an "Update version to X" commit. Pushing the tag is enough.
• The Homebrew formula should pass the version when it moves to the next release. One way, with no change to ./build: set ENV["GOFLAGS"] = "-ldflags=-X=github.com/square/certigo/cli.version=#{version}" before system "./build". I tested that GOFLAGS form with ./build, but not inside Homebrew.

Generated with Claude Code