In order to take advantage of the new BuildInfo it's ideal (imo) to replace the before classic best practice:
go build with -ldflags -X main.version=1.2.3 by go install pkg@v1.2.3
But go install doesn't simply let you specify where to install the binary. It puts it in GOPATH/bin when on the native architecture and GOPATH/bin/$arch/ when not; which makes it hacky and hard to just produce the binaries in a multi arch CIs
Example: before:
CGO_ENABLED=0 GOOS=windows go build -a -ldflags \
'-s -X fortio.org/fortio/version.version=1.28.0 -X "fortio.org/fortio/version.buildInfo=2022-04-26 00:40 57e9d8f01c342a4c1b5d96f883f81128b04d991a"' \
-o /tmp/fortio.exe fortio.org/fortio
after/now
GOPATH=/build CGO_ENABLED=0 GOOS=darwin /usr/local/go/bin/go install -a -ldflags -s fortio.org/fortio@v1.29.0-pre16
mv -f /build/bin/*_*/fortio* /build/bin
rmdir /build/bin/*_*
I end up having to use GOPATH to try to set where the binary ends up as well as using some hacks to deal with native vs non native arch
Let me know what you think
In order to take advantage of the new BuildInfo it's ideal (imo) to replace the before classic best practice:
go buildwith-ldflags -X main.version=1.2.3bygo install pkg@v1.2.3But
go installdoesn't simply let you specify where to install the binary. It puts it in GOPATH/bin when on the native architecture and GOPATH/bin/$arch/ when not; which makes it hacky and hard to just produce the binaries in a multi arch CIsExample: before:
after/now
I end up having to use GOPATH to try to set where the binary ends up as well as using some hacks to deal with native vs non native arch
Let me know what you think