search

gruntwork-io / git-xargs

git-xargs is a command-line tool (CLI) for making updates across multiple Github repositories with a single command.
https://blog.gruntwork.io/introducing-git-xargs-an-open-source-tool-to-update-multiple-github-repos-753f9f3675ec
Apache License 2.0
935 stars 62 forks source link

--version info missing when git-xargs is installed via go get #28

Closed zackproser closed 1 year ago

zackproser commented 3 years ago

The CircleCI job for git-xargs currently sets the main go package's VERSION variable to the $CIRCLE_TAG which is either the branch name or the tag name.

This means that when we build and publish binaries through CircleCI and programmatically attach them to a new release, they correctly have their internal VERSION value set to the tag of the release and, therefore, when you run git-xargs --version against them you get back the associated tag, e.g., git-xargs version v0.0.5.

However, when you install git-xargs via go get github.com/gruntwork-io/git-xargs, the package is downloaded from Github and then built in your defined or default $GOBIN directory. In this case, the main package's VERSION value remains unset, so running git-xargs with the --version flag returns an error.

One initial idea would be to update a VERSION file in the repo each time we do a release - so that the HEAD of the default branch contains a VERSION file which always matches the latest release's tag.

brikis98 commented 3 years ago

Another option is to update the version logic in go-commons to look up the latest Git ref or tag if the version param isn't set.

zackproser commented 3 years ago

Another option is to update the version logic in go-commons to look up the latest Git ref or tag if the version param isn't set.

Ah yeah that would probably be easier to maintain going forward than having to thrash on a file in the repo itself.

zackproser commented 1 year ago

This remains an issue to my knowledge, but I won't be able to address it myself anytime soon and the issue is stale.