runtime/debug: document BuildInfo.Main.Version == "(devel)" #29228
Comments
mark-rushakoff
changed the title
|
We could perhaps detect the case where the main module happens to be a pristine checkout with a semantically-versioned tag, although that might be misleading if some other module has a cyclic requirement specifying a higher version than the tag. |
|
+1. I thought being able to print the program’s main module’s version was the whole point of embedding build information into the binary. |
|
#26404 (comment) is some separate uncertainty about when and why I think this issue is still fully separate from #26404, as this is just about documenting |
|
It looks like one way to get the version to show up, is to make a new module referring to the one you actually want to build; and then build the target module. |
Or even just any of the current VCS state. For Caddy's builds, we use tag if clean, or if not clean: nearest tag, commit SHA, and build date (although I can understand why build date is a bad idea if seeking reproducible builds). For now, @mark-rushakoff's workaround is quite handy. +1 to this though, some version info on the main module would be immensely helpful. |
|
As observed in #33926, currently it's possible to end up building a binary with the same main module version but with different dependency versions. People who intend to use the main module version as the binary version should be careful. |
Using the “main module” version as the binary version (in the sense of https://tip.golang.org/cmd/go/#hdr-The_main_module_and_the_build_list) should be fine as long as the module doesn't have filesystem-local Unfortunately, that is not the version that the So I agree that the |
|
Will this be a high priority for Go 1.14? It could really ease the burden of build-from-souce workflows. Like, a lot. |
See golang/go#29228
|
@mholt, this is unlikely to happen in Go 1.14. (We have a pretty full slate of issues already, and any time the |
|
Is using the git command really a requirement of this feature? Wouldn't it be possible to get the relevant metadata directly from .git/HEAD? |
|
@mback2k,
|
|
The original point of this issue was simply documenting what it means when BuildInfo.Main.Version returns the string |
BuildInfo.Main.Version always returns "(devel)". I oppose documenting this, because I believe this is a bug: BuildInfo.Main.Version always returns "(devel)" even when the main module is versioned at HEAD. Documenting that it always returns "(devel)" makes it appear as correct behavior and makes it hard or impossible to change later. Let's fix the actual problem, not document the bug as expected behavior. |
|
@mholt, we can document the current behavior in a way that does not promise that behavior for all time. For example, we can document that |
|
nit:
The intention was that the BuildInfo.Main is the module that contains the main package, not the main module described in https://golang.org/cmd/go/#hdr-The_main_module_and_the_build_list I hope correcting the documentation error will help explaining this BuildInfo.Main.Version == "(devel)" case. |
|
Yeah, I think what we want is the version for the "main module" - the module that contains the main package. |
The go-modules approach is a bit broken: golang/go#29228 To resolve that, we now compute that version using `git describe` and set it using `ldflags`. While this is not as nice/builtin as the other approach, it at least works all the time and across go versions. Furthermore, I did refactor the Makefile in preparation for an AUR package that builds from source and for building release artifacts in CI.
|
While the main module still shows up as "(devel)" for just |
|
How would one build a binary (go service in docker image for instance) from ci/docker from a tag to get said tag in the binary being built? |
|
As far as I know, there's no good way to do this (and it appears this issue is somewhat codifying that we'll never know). I'd love to be able to access my current version as it would appear had I created some other module and used For my docker builds, I pass something in via |
|
I use the putting it here in case it helps someone else: DOCKER_BUILDKIT=1 docker build --ssh default ...and dockerfile with # syntax=docker/dockerfile:experimental
FROM golang as build
ARG VERSION
...
RUN git config --global url.ssh://git@somePrivateRepo/.insteadOf https://somePrivateRepo/
RUN mkdir -m 700 /root/.ssh && ssh-keyscan -4 -t rsa somePrivateRepo > /root/.ssh/known_hosts
RUN --mount=type=ssh go get -v -a -ldflags -s ... somePrivateRepo/pkg/path@${VERSION}it would be so much easier for |
The `$Id$` which can be auto-expanded in files via the `ident` attribute does not function the same as the old CVS `$Id$` keyword. In CVS, the keyword expansion was updated on every commit, to contain the current commit id. In git, it is expanded with the identifier of the _blob it is found in_. That is, previous to this commit, the `$Id$` (and hence the reported "version hash") was f220e479c5d8d85c7b753e95dc5fe0b67bbfbd38 -- and had been since the file was changed last, in f386360. Remove the misleading hash, and attendant git attributes file. It will frequently mislead callers that the version has not changed when, in reality, it has. Git itself does not have a way to embed "the current commit hash" into a file in a way that is updated whenever the commit changes. Nor does Go natively have a way to embed it into the binary at build time, though this may change in the future[1]. As alluded to in that ticket, most projects elect to pass in the build-time commit information via something like: ``` GIT_COMMIT=$(git rev-parse HEAD) go build -ldflags "-X main.gitCommit=$(GIT_COMMIT)" ``` However, smokescreen does not currently have any build system external to `go build` which could embed the above logic. Rather than choose a build system and introduce a new dependency, remove the misleading hash entirely. [1] golang/go#37475 and also golang/go#29228
|
Wouldn't adding a Is there a separate issue for this? I couldn't find it. I implemented it in the middle of writing this comment... here it is |
|
Change https://golang.org/cl/281912 mentions this issue: |
|
@Fryuni The main module doesn't have a version. If it did, MVS would need to work differently in the case where another module requires a higher version of the main module. It may also be misleading if a binary appears to be built from a published version (authenticated by the sumdb) but was actually built from a local checkout with modifications. Go 1.16 supports building and installing with #37475 is also an accepted but unimplemented proposal to automatically stamp VCS information into binaries. |
What version of Go are you using (
go version)?What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
Repro case is https://github.com/mark-rushakoff/debug-module-version-demo. It's a module, and its main.go contents are a simple use of
debug.ReadBuildInfo:What did you expect to see?
I expected to see the first line print
github.com/mark-rushakoff/debug-module-version-demo version v0.0.0-20181213...when checked out at an arbitrary commit, orgithub.com/mark-rushakoff/debug-module-version-demo version v0.0.1when checked out at tag v0.0.1. I tried bothgo run .andgo build . && ./debug-module-version-demobut both cases printed(devel).What did you see instead?
Based on the behavior I've observed, it looks as though the main module returned by
debug.ReadBuildInfois hardcoded to(devel)for the main module, which I assume is intended behavior. If so, that's unfortunate for use cases likemycmd versionto easily print the module version of the software being built; but it should be documented.The current documentation at https://tip.golang.org/pkg/runtime/debug/#ReadBuildInfo does not mention
(devel)in any way, nor does it mention any special behavior of theMainmodule./cc @hyangah since you're on git blame for src/runtime/debug/mod.go.
The text was updated successfully, but these errors were encountered: