search

echocat / gradle-golang-plugin

Gradle plugin to build, test and do other stuff of Golang projects.
https://github.com/echocat/gradle-golang-plugin
Mozilla Public License 2.0
44 stars 8 forks source link

Existing GOROOT variable will cause in fail of build Toolchain. #9

Closed sbulman closed 7 years ago

sbulman commented 7 years ago

I am trying to run a gradle build in a Docker container. The prepareToolchain task fails with the following message:

"Downloaded and extracted bootstrap to /root/.go/sdk/bootstrap but it could not be validated as working go installation."

Any ideas what I would need to do to solve this or what might be causing this error message?

Thanks, Simon

blaubaer commented 7 years ago

Hi Simon,

Could you please provide your build.gradle file and the facts about your operating system to understand the problem better? Please also capture a run of your build process with more details: ./gradlew --stacktrace --info build

Right now for me only I trapped one time in this problem - but this was only related to windows installations because on windows we download a .zip file of the bootstrap instead of a .tar.gz on the other operating systems. The problem in this context was: The .zip of golang could not extract directly from as a stream and have to buffered at first on the disk. The result was an uncompleted extract version of the bootstrap version of golang.

Cheers, Gregor

sbulman commented 7 years ago

HI Gregor,

This looks like a similar issue to https://github.com/echocat/gradle-golang-plugin/issues/10. If I manually export GOROOT to /root/.go/sdk/bootstrap and add /root/.go/sdk/bootstrap/bin to PATH as per the golang installation instructions (when installing to a non default directory) the prepareToolchain task appears to succeed. I suggest you set this as a duplicate of that issue.

Thanks, Si

blaubaer commented 7 years ago

Hi @sbulman and @goostleek!

I found the reason for this bug. If someone calls on a go any binary go version with a GOROOT variable is set (probably set to an not existing installation) it will cause in a very strange behavior:

$ set GOROOT=C:\foobar
$ %USERPROFILE%\.go\sdk\bootstrap\bin\go version
go: cannot find GOROOT directory: C:\foobar

$ set GOROOT=
$ %USERPROFILE%\.go\sdk\bootstrap\bin\go version
go version go1.7.1 windows/amd64

Same behavior an other operating systems.

I prepare a new version that will prevent this with explicitly removing in every case the already existing GOROOT & co. environment variables.

Cheers, Gregor

sbulman commented 7 years ago

Thanks for this fix. It 'almost' worked for me out of the box. In my fresh Docker container (debian linux) that only has openjdk I had to create an empty /usr/local/go directory.