Allow running outside of go workspace

[nothingmuch]

Our CI system checks out git repositories with no consideration for go workspace layouts.

go test still works inside the checkout directory, but it's impossible to use overalls to run it without shuffling things around

[deankarn]

Hey @nothingmuch I may need a bit more information; I would have thought that go test would not have worked either as how would it know where it's dependant packages are?

maybe an example of directory structure of where the project and it's dependencies are cloned would clear things up for me.

Also do you use go get to retrieve the dependant packages?

Possible Blocking Issue

I'll use github.com/go-playground/validator as an example:

So when coverage is created the resulting lines within the file actually contains a path to the go file + line number info etc... and when using a service such as coveralls to monitor your test coverage it adds the repo as github.com/go-playground/validator and expects the path(s) within the coverage to match like so:

github.com/go-playground/validator/validator.go:296.10,300.20 2 1
github.com/go-playground/validator/validator.go:304.7,304.30 1 1
github.com/go-playground/validator/validator.go:300.20,302.8 1 1
github.com/go-playground/validator/validator.go:304.30,305.22 1 1
github.com/go-playground/validator/validator.go:313.26,316.6 2 1
github.com/go-playground/validator/validator.go:318.51,323.28 2 1
github.com/go-playground/validator/validator.go:329.6,329.21 1 1
github.com/go-playground/validator/validator.go:368.6,368.12 1 1

but if I have the project in a different directory say my home directory under a tmp folder the coverage path(s) would look like:

_/Users/dean/tmp/validator.go:53.31,55.19 1 1
_/Users/dean/tmp/validator.go:64.4,64.75 1 1
_/Users/dean/tmp/validator.go:55.19,59.57 2 1
_/Users/dean/tmp/validator.go:59.57,60.14 1 1
_/Users/dean/tmp/validator.go:71.18,79.3 5 1
_/Users/dean/tmp/validator.go:83.129,91.14 5 1

and since they will not match, it will report 0% test coverage.

I originally had this problem using semaphore CI as they clone the repo outside of the $GOPATH and add a symlink to it under the $GOPATH, however they cd'd into the cloned path and not the symlinked one and therefore the paths didn't match and that's why overall want the project argument; so it can look under the matching path.

[nothingmuch]

I'm sorry I misremembered, and I thought for our homebrew solution this works with relative paths. Turns out we're fixing up the checkout directory to be a valid go workspace layout.