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: a few go tests fails on host with no network connection #26007

Closed
mikioh opened this issue Jun 22, 2018 · 9 comments

Comments

Projects
None yet
5 participants
@mikioh
Copy link
Contributor

commented Jun 22, 2018

What version of Go are you using (go version)?

tip

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

any

What did you do?

run all.bash on a standalone host

What did you expect to see?

no failure

What did you see instead?

a few? vendored packages under cmd/go/internal tried to fetch external resources unconditionally.

@myitcv

This comment has been minimized.

Copy link
Member

commented Jun 22, 2018

2018/06/22 09:45:48 git clone --mirror https://vcs-test.golang.org/git/gitrepo1 /tmp/gitrepo-test-046875646/gitrepo2 in : exit status 128:
        Cloning into bare repository '/tmp/gitrepo-test-046875646/gitrepo2'...
        fatal: unable to access 'https://vcs-test.golang.org/git/gitrepo1/': Could not resolve host: vcs-test.golang.org
FAIL    cmd/go/internal/modfetch/gitrepo        25.142s

/cc @rsc @bcmills

@ianlancetaylor ianlancetaylor added this to the Go1.11 milestone Jun 22, 2018

@ianlancetaylor ianlancetaylor changed the title cmd/go/internal: all.bash fails on standalone host cmd/go: a few go tests fails on host with no network connection Jun 23, 2018

@jcajka

This comment has been minimized.

Copy link
Contributor

commented Jun 26, 2018

I have looked in to this a bit as I'm hitting this issue on Fedora build system(koji) which is disconnected from the internet. Where I would love to run as much as possible from the test suite to smoke test the build.

Also I have opened the CL120735 with possible workaround. Base on the discussion with @ianlancetaylor there I plan to bring this topic up on golang-dev to solicit more feedback.

@jcajka

This comment has been minimized.

Copy link
Contributor

commented Jun 29, 2018

Investigated further and it seems that the HasExternalNetwork() guarding the check out is set to the true even in short mode, although other tests seem to have it set correctly and the flag is set in tests invocation. Expanding the guard with the testing.Short() leads to correct skip of the tests. Digging further.

@jcajka

This comment has been minimized.

Copy link
Contributor

commented Jun 29, 2018

More digging in.

It seems that there is some issue with the generated test binaries as in reduce reproducer(https://play.golang.org/p/y2fWT66LK86 , needs to be placed intree so it have access to the internal package) seems to always execute the first branch(i.e. incorrect value of HasExternalNetwork) regardless of setting of the short mode. This seems to only affect the testMain/HasExternalNetwork, detection of short mode seems to be fine in individual tests(commenting out the testmain bits).

I haven't examined the generated binaries yet. I have observed same behavior with go1.10. I will continue digging on Mon.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jun 29, 2018

testing.Short is only reliable after flag.Parse has been called. If your TestMain function called flag.Parse, it would work.

I've lost track now. Is there a test case in the standard library that is using the external network even though it uses testenv.HasExternalNetwork?

@jcajka

This comment has been minimized.

Copy link
Contributor

commented Jul 2, 2018

You are right I have missed that, but to be honest it is kind of counter intuitive and it is the core of this issue.

Yes and no, no all are guarded by the testenv.HasExternalNetwork, but yes as you said it is not yet initialized at that point of time(in this "vgo" case).

I will update the CL with correct fix for this bug. And for go1.12 I will commit to make "long" tests be possible to be executed without networking via the env var.

@gopherbot

This comment has been minimized.

Copy link

commented Jul 2, 2018

Change https://golang.org/cl/120735 mentions this issue: cmd/go: call flag.Parse to properly initialize test environment variables

@gopherbot gopherbot closed this in b55fe6a Jul 2, 2018

@jcajka

This comment has been minimized.

Copy link
Contributor

commented Jul 13, 2018

This seems to got reintroduce with latest merge of vgo.
Could we get it fixed? @rsc Should I open yet another CL?

It seems that the test got moved around as its now located in different test package.

2018/07/13 14:31:14 git clone --mirror https://vcs-test.golang.org/git/gitrepo1 /tmp/gitrepo-test-996701800/gitrepo2 in : exit status 128:
	Cloning into bare repository '/tmp/gitrepo-test-996701800/gitrepo2'...
	fatal: unable to access 'https://vcs-test.golang.org/git/gitrepo1/': Could not resolve host: vcs-test.golang.org
FAIL	cmd/go/internal/modfetch/codehost	0.307s

Unfortunately I do not have power to reopen this issue.

@gopherbot

This comment has been minimized.

Copy link

commented Jul 13, 2018

Change https://golang.org/cl/123735 mentions this issue: cmd/go: call flag.Parse to properly initialize test environment variables

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.