New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/go: runtime/debug build information not populated for test binaries when package name is not 'main' #33976
Comments
I ended up on this issue while investigating how to access (non Go) files located in a sub-directory of my Go module. The access should happen from tests located in sub-sub-package. So I tried the same as @bcmills is describing in this issue and I wanted to access Questions:
|
Just as a note, using func moduleBasePath(t *testing.T) string {
t.Helper()
err := os.Setenv("GO111MODULE", "on")
if err != nil {
t.Fatalf("unable to set GO111MODULE env var: %v", err)
}
cmd := exec.Command("go", "list", "-f", "{{.Module.Dir}}")
out, err := cmd.Output()
if err != nil {
t.Fatalf("failed to evaluate Go module base path: %v", err)
}
return strings.TrimSpace(string(out))
} |
That is the bug described in this issue. |
Note that running |
OK, understood. So this would not have helped me anyway.
I was under the impression, that the buildinfo has been left out intentionally and not that it is a bug. Good to hear, that it is considered a bug. |
That is not clear to me. Is this not the same in the case of tests? My understanding is, that |
Yes.
The module that contains the test is the module containing the working directory, yes. However, that directory does not indicate the version of that module, and the versions reported by |
Thanks for your detailed explanation. This comment made it clear to me with the provided example. For my use case this does not matter, because the "main module" and "the module containing package main" are the same. |
I am exploring adding some logic and maybe a feature or two to I can probably get my ideas to work with a different testing strategy, but the new features would have to come with a big caveat about not working in tests since Has anyone investigated the level of effort to fix this? I am willing to help given some suggestions about where to start digging into the issue. |
I also have found that when the package is named |
I am working on a project that delivers a binary built with I guess we can fall back to the old |
This bug hit me as well as we use module info to start some server based on the availability on the system. |
Probably the condition here needs to be updated: I'm not sure exactly what to update it to, though. |
What did you do?
https://play.golang.org/p/0ITNcl4kXGN
What did you expect to see?
(https://play.golang.org/p/0ITNcl4kXGN)
What did you see instead?
CC @jayconrod @rsc; see also #33975.
The text was updated successfully, but these errors were encountered: