Skip to content
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

Open
bcmills opened this issue Aug 30, 2019 · 8 comments
Labels
Milestone

Comments

@bcmills
Copy link
Member

@bcmills bcmills commented Aug 30, 2019

What did you do?

https://play.golang.org/p/0ITNcl4kXGN

$ gotip version
go version devel +8c5de667 Fri Aug 30 08:28:40 2019 +0000 linux/amd64

foo$ gotip mod init foo
go: creating new go.mod: module foo

foo$ cat > foo_test.go
package foo_test

import (
        "runtime/debug"
        "testing"
)

func TestBuildInfo(t *testing.T) {
        info, ok := debug.ReadBuildInfo()
        if !ok {
                t.Fatal("no debug info")
        }
        t.Log(info.Main.Version)
}

foo$ go test

What did you expect to see?

=== RUN   TestBuildInfo
--- PASS: TestBuildInfo (0.00s)
    foo_test.go:13: (devel)
PASS

(https://play.golang.org/p/0ITNcl4kXGN)

What did you see instead?

--- FAIL: TestBuildInfo (0.00s)
    foo_test.go:11: no debug info
FAIL

CC @jayconrod @rsc; see also #33975.

@bcmills bcmills added this to the Go1.14 milestone Aug 30, 2019
@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
@breml
Copy link
Contributor

@breml breml commented Dec 19, 2019

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.
We have it working with a relative path (e.g. ../../../folder/file) but it would be beneficial to have a less brittle way of accessing these files (especially for the case of refactoring).

So I tried the same as @bcmills is describing in this issue and I wanted to access info.Main.Path with the end goal of being able to access my files with info.Main.Path + "/folder/file".

Questions:

  1. Is my assumption correct, that info.Main.Path would contain the basepath for the module, if the buildinfo would be available in test builds?
  2. Why is the the buildinfo currently not available in test builds?
@breml
Copy link
Contributor

@breml breml commented Dec 19, 2019

Just as a note, using go list does work to get details about Go modules. E.g.:

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))
}
@bcmills
Copy link
Member Author

@bcmills bcmills commented Dec 19, 2019

  1. Is my assumption correct, that info.Main.Path would contain the basepath for the module, if the buildinfo would be available in test builds?

info.Main.Path in general contains a module path, not a filesystem path.

  1. Why is the the buildinfo currently not available in test builds?

That is the bug described in this issue.

@bcmills
Copy link
Member Author

@bcmills bcmills commented Dec 19, 2019

Just as a note, using go list does work to get details about Go modules. E.g.:

Note that running go list in the working directory of a test will tell you about the module that contains the test itself, not the main module in which the test was built.

@breml
Copy link
Contributor

@breml breml commented Dec 19, 2019

  1. Is my assumption correct, that info.Main.Path would contain the basepath for the module, if the buildinfo would be available in test builds?

info.Main.Path in general contains a module path, not a filesystem path.

OK, understood. So this would not have helped me anyway.

  1. Why is the the buildinfo currently not available in test builds?

That is the bug described in this issue.

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.

@breml
Copy link
Contributor

@breml breml commented Dec 19, 2019

Just as a note, using go list does work to get details about Go modules. E.g.:

Note that running go list in the working directory of a test will tell you about the module that contains the test itself, not the main module in which the test was built.

That is not clear to me. Is this not the same in the case of tests? My understanding is, that go test builds for every package a test binary and executes it. The guarantee is, that the current working directory is actually the directory that contains the test. So therefore, the module that contains the test and the module the test was built for is the same (or is there something special going on in regards to modules when building tests?).
This is why go test -o test ./... does not work (error message: cannot use -o flag with multiple packages).

@bcmills
Copy link
Member Author

@bcmills bcmills commented Dec 19, 2019

The guarantee is, that the current working directory is actually the directory that contains the test.

Yes.

So therefore, the module that contains the test and the module the test was built for is the same (or is there something special going on in regards to modules when building tests?).

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 go list -m all will not be accurate: those versions are determined by the “main module” (in the sense of https://tip.golang.org/cmd/go/#hdr-The_main_module_and_the_build_list), not “the module containing package main”. (See #33975.)

@breml
Copy link
Contributor

@breml breml commented Dec 19, 2019

However, that directory does not indicate the version of that module, and the versions reported by go list -m all will not be accurate: those versions are determined by the “main module” (in the sense of https://tip.golang.org/cmd/go/#hdr-The_main_module_and_the_build_list), not “the module containing package main”. (See #33975.)

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.