Include git short hash or release indicator in contrib.Version()

[Aneurysm9]

It would be ideal if the contrib.Version() function could include information about the git commit used if it is not a release tag. See comment on addition of contrib.Version(). Unfortunately, the Makefile-based approach used in the project referenced there looks like it would only work at the point of building an executable, which is outside the purview of this project. We may be able to use debug.ReadBuildInfo.

[evantorrie]

As @Aneurysm9 notes, what we're providing here are libraries, not standalone binaries (with the exception of the "examples").

We don't have control over build arguments of consuming applications to set link variables as used in the Postgres example and nearly all applications will consume the libraries as versioned modules, i.e. using the exact git commit corresponding to the tag that was released.

However, we can't insert the git commit sha into the source code at the time we merge the prerelease branch to main, because the git commit in main doesn't yet exist - Catch 22. We could add an additional "version update" commit immediately after merging that updated the git commit in the source to be the same as the tagged version, but that seems messy. And it still doesn't help with trying to embed git commit information for subsequent commits of the source code.

I looked over the debug.ReadBuildInfo() API. It would allow a library module to introspect the running application's build information to extract the module versions specified in the application's go.mod. This would usually be a specific version tag, but may also be a Go module pseudo-version if someone is trying to use a non-tagged version of a module from the github repo, e.g. v0.11.1-0.20200828001137-f598244c335d. We could iterate through the list of modules until we found go.opentelemetry.io/contrib and use the version specified in debug.ReadBuildInfo(). While it does include replace directives, it doesn't contain any useful version information for a go.mod containing a replace directive specifying a relative directory.

What are your thoughts on implementing a solution such as this?

Note: I also found this issue which describes future Go enhancements to automatically embed git sha/version information from the main repo into a binary (able to be disabled optionally).

[MrAlias]

@evantorrie I think you make a good point in that this is not going to be built into a library. I'm going to relabel this for after GA, but I'm not entirely sure it is something we want to spend too much time on in light of the good points made.