`dispatch version` should print version in semver format

[chicoxyzzy]

Current output:

dispatch version devel 467c20a69dd1cd3e342d0c6c53f13c6981dfe260

Expected output:

dispatch version 0.2.0, build 467c20a69dd1cd3e342d0c6c53f13c6981dfe260

I think that we can also make the hash shorter. GitHub uses 7 symbols and Docker uses that number of symbols too.

➜ docker -v
Docker version 26.1.1, build 4cf5afa

[chicoxyzzy]

So I made a little research of Docker CLI repo and how they manage versions. I like the idea of having VERSION file in the root of the git project as a single source of truth. They somehow use the ENVVARS variable to get all the info that is printed by docker -v and also docker version command with a detailed information:

➜ docker version
Cannot connect to the Docker daemon at unix:///Users/chicoxyzzy/.docker/run/docker.sock. Is the docker daemon running?
Client:
 Cloud integration: v1.0.35+desktop.13
 Version:           26.1.1
 API version:       1.45
 Go version:        go1.21.9
 Git commit:        4cf5afa
 Built:             Tue Apr 30 11:44:56 2024
 OS/Arch:           darwin/amd64
 Context:           desktop-linux

I think that we can start with passing ldflags in our Makefile to the linker to override existing variables in compile time. We can also provide a Makefile rule to bump version (update VERSION file content and set a git tag) to simplify the release routine.

[chriso]

FYI that the output depends on the installation method. You should only see devel if you're installing from an untagged SHA.

If you install using go install ...@latest or brew install you'll get the latest tagged release, and you'll instead see something like this:

~ $ go install github.com/dispatchrun/dispatch@latest
go: downloading github.com/dispatchrun/dispatch v0.2.0
~ $ dispatch version
dispatch version v0.2.0

You could have a look at what debug.ReadBuildInfo() returns here and update it to print both the tag (if found) and SHA. I don't think it's worth going to more effort to print the SHA though in all cases; this information isn't relevant to the end user, and if the tag is known the SHA can be located if necessary using git.

I'd avoid a custom build process using a Makefile and passing ldflags. It can get out of sync with the repo, and not all installation methods will go through this path. For example, go install github.com/dispatchrun/dispatch@latest will ignore the Makefile and any custom ldflags.

[chicoxyzzy]

@chriso Thank you for the clarifications! For some reason I see hash 467c20a69dd1cd3e342d0c6c53f13c6981dfe260 as a version after installing dispatch from homebrew. Is it intended?

[chriso]

Looks like a bug somewhere in our build system. We're using https://goreleaser.com (via https://github.com/dispatchrun/dispatch/blob/main/.github/workflows/release.yml) to build the binaries, create releases on GitHub (e.g. https://github.com/dispatchrun/dispatch/releases/tag/v0.2.0) and then publish the Homebrew formula (https://github.com/dispatchrun/homebrew-dispatch/blob/main/Formula/dispatch.rb).

I downloaded the latest GitHub release (https://github.com/dispatchrun/dispatch/releases/download/v0.2.0/dispatch_0.2.0_darwin_arm64.tar.gz) manually and confirmed that the tag is missing from dispatch version output:

$ tar xvf dispatch_0.2.0_darwin_arm64.tar.gz 
x README.md
x dispatch
$ ./dispatch version
dispatch version devel 467c20a69dd1cd3e342d0c6c53f13c6981dfe260

The SHA is correct for the v0.2.0 tag, but the information is missing from the binary.

Digging some more, it looks like we need to follow this process ("proxy" our module before it's built) to embed the tag correctly: https://goreleaser.com/cookbooks/build-go-modules/