Update Go in CI build.

[hansrodtang]

Travis OSX images ship with an older version of Go (1.3.1) than their normal Ubuntu ones, making the build fail on a go get, this updates it to Go 1.3.3. Same goes for AppVeyor.

Leaving a request for Travis and AppVeyor to update their environment would be ideal, but for now this works.
The Travis build will also only update if it is outdated.
Still some failures on the Travis build, but they are unrelated to this.

[joefitzgerald]

LGTM. Thanks!

[hansrodtang]

An update: The tests fail because the Go version installed is still not new enough.

It seems like for the command line tools the install path (which unlike normal packages is in the GOROOT path) for each tools/cmd package is hardcoded into go get making it the only moved packages that need Go 1.4 to work. Tried it with a Go development version and all the tests passed, except for the one mentioned in the issue I just posted, #93.

When Go 1.4 comes out in two weeks or so it should work without having to do anything.

The real question is why AppVeyor passes. Looks like only a few test are performed.

[joefitzgerald]

I did some digging last night (and focused a single test). The issue appears to be that vet and cover get installed to $GOPATH/bin, whereas they used to get installed to GOTOOLDIR:

0.00s$ ls -al $HOME/go/bin
total 54936
drwxr-xr-x  7 travis  staff      238 Nov 15 23:03 .
drwxr-xr-x  5 travis  staff      170 Nov 15 23:03 ..
-rwxr-xr-x  1 travis  staff  5352656 Nov 15 23:03 cover
-rwxr-xr-x  1 travis  staff  4869824 Nov 15 23:03 goimports
-rwxr-xr-x  1 travis  staff  5609360 Nov 15 23:03 golint
-rwxr-xr-x  1 travis  staff  6509056 Nov 15 23:03 goreturns
-rwxr-xr-x  1 travis  staff  5777376 Nov 15 23:03 vet
before_script.12
0.00s$ ls -al /usr/local/Cellar/go/1.3.3/libexec/pkg/tool/darwin_amd64
total 50184
drwxr-xr-x  15 travis  admin      510 Nov 15 23:03 .
drwxr-xr-x   3 travis  admin      102 Oct  1 10:39 ..
-rwxr-xr-x   1 travis  admin   256388 Oct  1 10:39 6a
-rwxr-xr-x   1 travis  admin   492912 Oct  1 10:39 6c
-rwxr-xr-x   1 travis  admin   846412 Oct  1 10:39 6g
-rwxr-xr-x   1 travis  admin   402152 Oct  1 10:39 6l
-rwxr-xr-x   1 travis  admin  3025648 Oct  1 10:39 addr2line
-rwxr-xr-x   1 travis  admin  4434480 Oct  1 10:39 cgo
-rwxr-xr-x   1 travis  admin    74812 Oct  1 10:39 dist
-rwxr-xr-x   1 travis  admin  3314768 Oct  1 10:39 fix
-rwxr-xr-x   1 travis  admin  3060512 Oct  1 10:39 nm
-rwxr-xr-x   1 travis  admin  4203664 Oct  1 10:39 objdump
-rwxr-xr-x   1 travis  admin  2134448 Oct  1 10:39 pack
-rwxr-xr-x   1 travis  admin   158072 Nov 15 23:03 pprof
-rwxr-xr-x   1 travis  admin  3256432 Oct  1 10:39 yacc

I think the issue might be some code that looks for the executable - it only looks in GOTOOLDIR, and doesn't use the PATH or $GOPATH/bin.

[joefitzgerald]

Yep, that's it. Vet and Cover now no longer install into GOTOOLDIR - they go to $GOPATH/bin.

[hansrodtang]

Yes, that is what I said. Which packages that end up in $GOTOOLDIR are hardcoded into go get, and the hardcoded references aren't changed in Go 1.3.3 (But are in the development builds). Normal tools packages in golang.org/x/ will work fine though since they don't depend on being in a special path.

Go only looks for tools in $GOTOOLDIR, the file ending up in $GOPATH is a "bug".

The recent change is here: https://codereview.appspot.com/168170043/patch/50001/60002

[hansrodtang]

A fix could be to roll back to the old paths and update them again in two or three weeks time when Go 1.4 is out.

[joefitzgerald]

It's really dumb they didn't use branches to maintain a valid version for go 1.3.x, while moving 1.4.x forward on master. I think you're right - there's really no solution here until 1.4 comes out. Thanks for all the help!

[joefitzgerald]

I'm temporarily leaving the old path for cover, as it's the only tool that is impacted - I call vet directly but cover needs to be in the correct location as go test -coverprofile is the thing using it. Fixed build here: https://travis-ci.org/joefitzgerald/go-plus/builds/41173887