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

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.

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.

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.

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?

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.

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

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.

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