Open artursv opened 7 years ago
if you are using the manual method, then building outside of a gopath is not supported. I will have to change the instructions to reflect this.
https://github.com/golang/go/issues/14566
Can you paste errors that you got when using the build.sh
?
actually I think that I have a solution that would allow installation simply with:
$/> go get github.com/wunderkraut/radi-cli/radi
I am still testing.
Here is the output of ./build.sh
❯ ./build.sh
***** Building RADI cli client.
This will build the radi-cli as a 'radi' binary for 'linux-amd64'.
(Override this by setting $GOOS and $GOARCH environment variables)
**** Building in containerized golang environment
make: stat: Makefile: Permission denied
make: Nothing to be done for 'build'.
Exited container
**** Containerized build complete
an executable binary has (hopefully) now been built
in ./bin/radi
**** Installation
This installer can now install the built binary for you,
if you don't want to do it manually.
The planned installation path is : /usr/local/bin
Would you like to me install a binary to that location? (y/n)
y
--> detected that sudo will be required, as you don't have write privelege to the target path
[sudo] password for arturs:
"./build/make.sh" install
---> Make-bundle: install (in .)
--> Installing last compiled binary (./bin/radi) to: /usr/local/bin
cp: cannot stat './bin/radi': No such file or directory
Makefile:26: recipe for target 'install' failed
make: *** [install] Error 1
Makefile
is executable,and it also clarifies the instructions for building manually (that go needs the source code to be inside of $GOPATH to build locally.)
There is also the option of using go get
to retrieve source code, which we are testing now.
@artursv can you test again with the latest effort?
@james-nesbitt make all still fails with the output I posted above.
I was however able to get the binaries with go get.
I will consider this issue mitigated, but keep it open to figure out what is going wrong with the Make
further information:
when building in a container in Fedora, it seems that the local volume bind does not work. The source code folder is empty where the bind occurs. This is some kind of docker failure that needs diagnosing.
After some one-on-one with @artursv we have discovered that his Fedora machine has some unknown configuration that prevents docker from mounting /home/*
paths into containers.
Possible causes:
This is not a bug in the toolset, but rather a docker issue on Fedora.
This looks hopeful: http://stackoverflow.com/questions/24288616/permission-denied-on-accessing-host-directory-in-docker
Testing with @artursv shows success.
Make fails with the following: