We moved one Go variable and every copy of our new CLI was told to upgrade

Описание и применение

Перемещение переменной версии в Go‑проекте привело к тому, что все опубликованные бинарники сообщали неверную версию и были отклонены API‑шлюзом. Исправление включало обновление флага linker‑flag и проверку версии перед подписанием.

Задача

A release workflow misconfigured a linker flag, causing all published binaries to report an incorrect version and be rejected by the API gateway.

Результат

All published binaries now report the correct semantic version, partners no longer receive false upgrade prompts, and the API gateway accepts valid requests.

Рабочий процесс

• 1. Update release workflow to use -X internal/buildinfo.version instead of -X main.version.
• 2. Add a pre‑sign check that runs the built binary’s version command and compares output to the git tag.
• 3. Sign and publish the binary only if the check passes.
• 4. Ensure the API gateway parses the version header correctly and does not downgrade unparseable values.

Доказательства

The release workflow builds it with go build and an ldflags option, -X main.version followed by the tag, which tells the Go linker to set the string variable version in package main to that value.

Источник

In 2.7.0 a tidy up moved build information out of main into a package of its own, internal/buildinfo, and the variable went with it.

Источник

The Go linker does not treat an -X naming a symbol that does not exist as an error, or even a warning. It ignores it.

Источник

The release workflow now runs the built binary with its version command and fails unless the output matches the tag, character for character, before anything is signed.

Источник