Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make build-in-docker fails with unknown error 526 #9

Closed
jamezpolley opened this issue Aug 20, 2019 · 6 comments
Closed

make build-in-docker fails with unknown error 526 #9

jamezpolley opened this issue Aug 20, 2019 · 6 comments

Comments

@jamezpolley
Copy link
Member

o get -u github.com/jteeuwen/go-bindata/
go: finding github.com/mitchellh/go-homedir v1.1.0
go: finding github.com/kardianos/osext v0.0.0-20190222173326-2bc1f35cddc0
go: finding github.com/progrium/basht v0.1.0
go: finding github.com/progrium/gh-release v2.2.1+incompatible
go: finding github.com/progrium/go-basher v0.0.0-20170201215011-ad5de635edd1
go: finding github.com/jteeuwen/go-bindata v3.0.7+incompatible
go: finding gopkg.in/yaml.v2 v2.2.2
go: finding gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405
go: downloading github.com/jteeuwen/go-bindata v3.0.7+incompatible
go: extracting github.com/jteeuwen/go-bindata v3.0.7+incompatible
go get -u github.com/progrium/gh-release/
go: downloading github.com/progrium/gh-release v2.2.1+incompatible
go: extracting github.com/progrium/gh-release v2.2.1+incompatible
go: downloading github.com/progrium/go-basher v0.0.0-20170201215011-ad5de635edd1
go: extracting github.com/progrium/go-basher v0.0.0-20170201215011-ad5de635edd1
go: downloading github.com/kardianos/osext v0.0.0-20190222173326-2bc1f35cddc0
go: downloading github.com/mitchellh/go-homedir v1.1.0
go: extracting github.com/kardianos/osext v0.0.0-20190222173326-2bc1f35cddc0
go: extracting github.com/mitchellh/go-homedir v1.1.0
go get -u github.com/progrium/basht/
go: downloading github.com/progrium/basht v0.1.0
go: extracting github.com/progrium/basht v0.1.0
go get -u github.com/jteeuwen/go-bindata/...
go get -u github.com/progrium/gh-release/...
go get -u github.com/progrium/basht/...
go get || true
go: downloading gopkg.in/yaml.v2 v2.2.2
go: extracting gopkg.in/yaml.v2 v2.2.2
/bin/bash: line 6: include/buildpacks.txt: Unknown error 526
make: *** [build] Error 1
Makefile:21: recipe for target 'build' failed
@jamezpolley
Copy link
Member Author

error 526 seems to be related to permissions on the mount not letting the process inside the docker container (running as uid 0) write to the file mounted into the container from the minikube vm and into the vm from my homedir.

https://minikube.sigs.k8s.io/docs/tasks/mount/ says that the mount created with --mount is going to be a 9P mount, and has various issues; while the default unchangeable driver mount does something different (and unspecified and unchangeable).

I've been able to work around this a little: I've run export MINIKUBE_MOUNT_PATH=${PWD/home/hosthome} and applied a small patch:

diff --git a/Makefile b/Makefile
index fc0994b..0b4455c 100644
--- a/Makefile
+++ b/Makefile
@@ -7,6 +7,8 @@ BUILD_TAG ?= dev
 BUILDPACK_ORDER := multi ruby nodejs clojure python java gradle scala play php go static
 SHELL := /bin/bash
 
+MINIKUBE_MOUNT_PATH ?= $PWD
+
 shellcheck:
 ifneq ($(shell shellcheck --version > /dev/null 2>&1 ; echo $$?),0)
 ifeq ($(SYSTEM),Darwin)
@@ -38,7 +40,7 @@ build-in-docker:
        docker build --rm -f Dockerfile.build -t $(NAME)-build .
        docker run --rm -v /var/run/docker.sock:/var/run/docker.sock:ro \
                -v /var/lib/docker:/var/lib/docker \
-               -v ${PWD}:/src/github.com/gliderlabs/herokuish -w /src/github.com/gliderlabs/herokuish \
+               -v ${MINIKUBE_MOUNT_PATH}:/src/github.com/gliderlabs/herokuish:rw -w /src/github.com/gliderlabs/herokuish \
                -e IMAGE_NAME=$(IMAGE_NAME) -e BUILD_TAG=$(BUILD_TAG) -e VERSION=master \
                $(NAME)-build make -e deps build
        docker rmi $(NAME)-build || true

I've created mlandauer/herokuish/pull/2 which has this patch; however, applying it would move us further from upstream.

@jamezpolley
Copy link
Member Author

I think I can see two alternatives here:

  • Use skaffold to build the herokuish image.

  • Looks like it would require a custom build script. Hrm.

  • Building the herokuish image from the minikube VM, which should be platform independent.

    • but the minikube vm doesn't seem to have "make", which makes this hard

The only real cross-platform solution I can think of right now would be to apply a handwave - push docker images for mlandauer/herokuish to dockerhub and use those for now. Once upstream is patched, we can change the dockerfiles in this repo to point to upstream instead.

@jamezpolley
Copy link
Member Author

@mlandauer I'm interested in your thoughts on this.

I feel like the patched-herokuish image is probably better off out-of-scope of the instructions for this repo anyway - ideally we'd be using the stock upstream images (which would mean that we never have to do anything to build them).

@mlandauer
Copy link
Member

Yup it is looking like a simple cross-platform build of herokuish isn't going to be straightforward based on what you've discovered. And yes ideally we shouldn't need to build it anyway as our patch will hopefully get merged upstream. What worries me, though, is the PR has been open a bit and I don't see any sign that it's getting merged.

@jamezpolley
Copy link
Member Author

I feel like it's probably less work to have an OA fork of herokuish (with automated builds on dockerhub) than it would be to work on a cross-platform build

@mlandauer
Copy link
Member

Worked around this by pushing a pre-built patched herokuish image to docker hub at https://hub.docker.com/r/mlandauer/herokuish and updated morph-ng to use that instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants