Why circle-ci doesn't run "go get" from the correct package path under $GOPATH?

From what I can tell, it uses some voodoo to trick “go get” into thinking it’s running in the correct package path to get around the internal import check. Unfortunately, the voodoo prepends “github.com” to the front of the package name, so it fails horribly for bitbucket:

go get -t -d -v ./…
bitbucket.org/infraworks/workspace_agent (download)
github.com/gorilla/websocket (download)
github.com/kr/pty (download)
golang.org/x/text (download)
bitbucket.org/infraworks/workspace_backend (download)
package github.com/infraworks/workspace_agent/go-fuse/unionfs
imports bitbucket.org/infraworks/workspace_agent/go-fuse/internal/testutil: use of internal package not allowed

go get -t -d -v ./… returned exit code 1

Please note that “github.com”, it comes out of nowhere. Nothing I have is hosted in github. When I ran the command manually through ssh, it became “./infraworks/workspace_agent”, which is correct, as we are not running in the right package path.

This is kind of lame… why circle-ci chose to not run “go get” from $GOPATH?

1 Like

This code dates back to before CircleCI supported BitBucket. I’ve escalated this issue internally.