Open lox opened 7 years ago
I just double checked the repo, so I'm either crazy - or hadn't enough ☕️, but I don't think we have any symlinks in here?
Yup, so the issue here is that the gopath is being created with a symlink in it to the checkout dir. For this to work in "the go way" it needs to be the other way, the gopath needs to have the code in it and the checkout dir would have to be a symlink to the folder in the gopath.
Basically, no symlink in gopath, as various go tools won't follow it as they will read the name of the symlink as what it points to and then try and traverse the gopath from there.
Right, the Go tools don't act as if the files are rooted at the path of the symlink. Instead they follow the symlink, which makes packages appear to be outside of the gopath.
@keithpitt Any idea how this can be solved? We at Sourcegraph want to switch from Circle CI to Buildkite (and pay for it), but currently we can't because this is preventing us from testing any of our Go projects.
@keithpitt oh hai, I'm also hitting this issue. I'm wondering if there's a way to specify a target directory for the git clone
so that I can do:
export GOPATH="$(pwd)"
git clone git@github.com:aybabtme/project.git $GOPATH/src/github.com/aybabtme/project
cd $GOPATH/src/github.com/aybabtme/project
./scripts/test.sh
This way I wouldn't need symlinks at all.
Hi @aybabtme! 👋🏻 You could set BUILDKITE_BUILD_CHECKOUT_PATH
in a pre-checkout
hook to accomplish that, although you'd need to have a gopath per-agent if you have multiple concurrent agents.
Unfortunately I haven't come up with a better solution to running golang projects on the host since I filed this issue. A docker container is probably your best bet.
Lots of Go's tools won't traverse a gopath that contains symlinks: https://github.com/tools/godep/issues/71
The suggested approach is to use a reverse symlink, so have the gopath directory the actual directory and have the checkout dir a symbolic link.