Use build info when available (go install)

[jmdacruz]

Currently, installing nancy via go install results in nancy --version returning 0.0.0-dev instead of the version that was actually installed. The solution is to add an init function that uses debug.ReadBuildInfo() from the runtime/debug package in order to get the actual version (if one is available). This is loosely based on the behavior of tools such as https://github.com/golangci/golangci-lint/blob/master/cmd/golangci-lint/mod_version.go#L9

This pull request makes the following changes:

• Adds an init() function on the buildversion package that attempts to retrieve the version information from debug.ReadBuildInfo() (if available, and if the build information is not overridden via the build CLI)

cc @bhamail / @DarthHater

[sonatypecla]

Thanks for the contribution! Before we can merge this, we need @jmdacruz to sign the Sonatype Contributor License Agreement.

[bhamail]

@jmdacruz Cool! I'll take a look at this. BTW, the CI build will probably succeed if you merge in the latest changes from the main branch. There were some recent fixes to Integration Tests.

[jmdacruz]

@bhamail I updated the fork with the upstream, but it looks like there's a an actual integration test failure caused by my code now: Error: pkg: semver: Parse((devel)): No Major.Minor.Patch elements found. I can reproduce this error locally with make docker-integration-tests, and I can also see that running the tests locally against main yields no errors.

Any pointers on what to look for on the integration tests?

Update: Found the issue, trying to find a workaround. Long story short, go build with no arguments results in a binary that will execute the new code on the init function, which results in the version being replaced with the string devel

[jmdacruz]

@bhamail done! I documented in the code the behavior of the debug.ReadBuildInfo() function: the version will be an empty string when debugging, and it will be (devel) when building locally with go build

[bhamail]

I like it! Thanks!!!

[jmdacruz]

@bhamail I think there's an unintended side effect: The version used when doing go install ... will be v1.0.34, and the CLI complains about the leading v:

Error: pkg: semver: Parse(v1.0.34): Invalid character(s) found in major number "v1"

Should I modify the PR to remove the leading v if present? I could try using github.com/blang/semver to ensure that the version will parse correctly

[bhamail]

Good catch. Yes, that sounds like a good change to me.

[jmdacruz]

Created #266 for fixing this