travis ci builds time out

[kevinburke]

The gps tests hang forever with travis. See https://travis-ci.org/kevinburke/dep/jobs/470109609 for an example. On my local machine they take 48 seconds so this seems like an anomaly and not something that will be solved by bumping the timeout further.

I think Travis CI is having a problem with a Mercurial build? And then this is causing everything to block.

See for example:

goroutine 256 [syscall, 19 minutes]:
syscall.Syscall6(0xf7, 0x1, 0x1f3c, 0xc4204231e0, 0x1000004, 0x0, 0x0, 0xc4202fa770, 0x2b960df718a0, 0x0)
	/home/travis/.gimme/versions/go1.10.7.linux.amd64/src/syscall/asm_linux_amd64.s:44 +0x5
os.(*Process).blockUntilWaitable(0xc42033d800, 0x0, 0x0, 0x3)
	/home/travis/.gimme/versions/go1.10.7.linux.amd64/src/os/wait_waitid.go:31 +0xc0
os.(*Process).wait(0xc42033d800, 0xc42047ac20, 0xc42033d800, 0xc4201d3b00)
	/home/travis/.gimme/versions/go1.10.7.linux.amd64/src/os/exec_unix.go:22 +0x6f
os.(*Process).Wait(0xc42033d800, 0xc42047abb0, 0x438f8a, 0xc42047aba0)
	/home/travis/.gimme/versions/go1.10.7.linux.amd64/src/os/exec.go:123 +0x39
os/exec.(*Cmd).Wait(0xc42047ab00, 0x0, 0x0)
	/home/travis/.gimme/versions/go1.10.7.linux.amd64/src/os/exec/exec.go:461 +0xea
os/exec.(*Cmd).Run(0xc42047ab00, 0x68, 0x2)
	/home/travis/.gimme/versions/go1.10.7.linux.amd64/src/os/exec/exec.go:305 +0x87
os/exec.(*Cmd).CombinedOutput(0xc42047ab00, 0x2, 0xc420423658, 0x2, 0x2, 0xc42047ab00)
	/home/travis/.gimme/versions/go1.10.7.linux.amd64/src/os/exec/exec.go:521 +0x283
github.com/golang/dep/vendor/github.com/Masterminds/vcs.base.run(0xc42033cf60, 0x2c, 0xc4200388c0, 0x4a, 0xc4200ae640, 0xc129f5, 0x2, 0xc420423658, 0x2, 0x2, ...)
	/home/travis/gopath/src/github.com/golang/dep/vendor/github.com/Masterminds/vcs/repo.go:219 +0x93
github.com/golang/dep/vendor/github.com/Masterminds/vcs.(*HgRepo).Ping(0xc420254870, 0x10)
	/home/travis/gopath/src/github.com/golang/dep/vendor/github.com/Masterminds/vcs/hg.go:303 +0x157
github.com/golang/dep/gps.(*baseVCSSource).existsUpstream(0xc4202fa6e0, 0x117efa0, 0xc42046a5a0, 0x2b960de4f000)
	/home/travis/gopath/src/github.com/golang/dep/gps/vcs_source.go:35 +0x4f
github.com/golang/dep/gps.(*sourceGateway).sourceExistsUpstream.func1(0x117efa0, 0xc42046a5a0, 0x117ece0, 0xc420258000)
	/home/travis/gopath/src/github.com/golang/dep/gps/source.go:593 +0x96
github.com/golang/dep/gps.(*supervisor).do(0xc42027ad80, 0x117ed20, 0xc4200a8050, 0xc129f5, 0x2, 0x4, 0xc4204238a0, 0x0, 0x0)
	/home/travis/gopath/src/github.com/golang/dep/gps/source_manager.go:716 +0xfc
github.com/golang/dep/gps.(*sourceGateway).sourceExistsUpstream(0xc42046a550, 0x117ed20, 0xc4200a8050, 0x2b960f1805f8, 0x0, 0xc42008c400)
	/home/travis/gopath/src/github.com/golang/dep/gps/source.go:592 +0x1f0
github.com/golang/dep/gps.(*sourceGateway).require(0xc42046a550, 0x117ed20, 0xc4200a8050, 0x1, 0x50, 0xbd8840)
	/home/travis/gopath/src/github.com/golang/dep/gps/source.go:650 +0x249
github.com/golang/dep/gps.newSourceGateway(0x117ed20, 0xc4200a8050, 0x1183ae0, 0xc4202fa6e0, 0xc42027ad80, 0xc4204d5960, 0x15, 0x1182340, 0xc42046a500, 0x0, ...)
	/home/travis/gopath/src/github.com/golang/dep/gps/source.go:296 +0x250
github.com/golang/dep/gps.(*sourceCoordinator).getSourceGatewayFor(0xc4200e4080, 0x117ed20, 0xc4200a8050, 0xc24de0, 0x23, 0xc24de0, 0x23, 0x0, 0x0, 0x0)
	/home/travis/gopath/src/github.com/golang/dep/gps/source.go:231 +0xef7
github.com/golang/dep/gps.TestGetSources.func1.1(0xc4202062d0)
	/home/travis/gopath/src/github.com/golang/dep/gps/manager_test.go:472 +0x110
testing.tRunner(0xc4202062d0, 0xc4202416e0)
	/home/travis/.gimme/versions/go1.10.7.linux.amd64/src/testing/testing.go:777 +0x16e
created by testing.(*T).Run
	/home/travis/.gimme/versions/go1.10.7.linux.amd64/src/testing/testing.go:824 +0x565

[kevinburke]

Possibly related to Masterminds/vcs#78.

[kevinburke]

Okay, narrowed down further... if you issue git ls-remote using the git protocol to a Mercurial repository on Bitbucket the command just hangs forever. Confirmed this in the stack trace as well.

git ls-remote git://bitbucket.org/mattfarina/testhgrepo

I don't think this will ever work unless Bitbucket changes their configuration. Should we detect this pair and return an error if so?