-v works on my mac. Where does it not work?

Surprised to hear this. I wrote the original Dockerfile on my mac.

On 18 December 2014 at 11:04, David Crawshaw notifications@github.com
wrote:

-v works on my mac. Where does it not work?

—
Reply to this email directly or view it on GitHub
#9372 (comment).

-v doesn't work when the docker client & server are on different machines that don't share a filesystem, so they can't bind mount. This is moby/moby#4023

-v is just being used to determine the mounting point on the container :-/ The source has be mounted on the host machine.

It's an overkill and is pretty backwards to share an fs in this particular case. I would like to pack the entire application package as an image and send it to the build server and have no dependencies to the host machine. It's also racy to adopt this model. How am I supposed to run two builds concurrently? By creating a new source point for each build?

The current version of Docker is for the convenience during development
e.g., when you don't know whether your application package builds(!) or you
have all necessary libraries installed yet. Usually, I have a window open
for a docker container running build and debugging in interactive mode (-it
and often with usb mount) and other windows to edit files, run gobind, or
other source generation tools. No more double goroot for cross-compilation
or android library installation headache.

For build-only purpose, we need a better mechanism - check adg's mobiley
idea. https://codereview.appspot.com/152770043/
It launches a builder server in a container, sends a tarball to the server
to build. The server responses with the built apk or build error logs.

I think either we need to use mobiley or, use a docker build+run+copy
solution dedicated for the build-only purpose.

On Wed Dec 17 2014 at 9:43:34 PM Burcu Dogan notifications@github.com
wrote:

-v is just being used to determine the mounting point on the container :-/
The source has be mounted on the host machine.

It's an overkill and is pretty backwards to share an fs in this particular
case. I would like to pack the entire application package as an image and
send it to the build server and have no dependencies to the host machine.
It's also racy to adopt this model. How am I supposed to run two builds
concurrently? By creating a new source point for each build?

—
Reply to this email directly or view it on GitHub
#9372 (comment).

To add to what @hyangah wrote, the current workflow is extremely convenient. I work with an app on my desktop in my normal GOPATH, where I can build and run it. Then I use a single command to build an .apk of the same program. Any replacement for the existing docker setup needs to replicate that. I'm open to any solution for features like concurrent and remote builds, as long as it can also do that.

Of more interest is getting rid of the android-related junk. In particular, AndroidManifest.xml, build.xml, jni/Android.mk, etc should all be derivable for normal apps. @adg's experiments with mobiley are about getting rid of that burden, which would help the developer experience. It will become more important when building for other platforms is supported, as those will require a different set of build junk and a tool should keep them in sync (ideally by automatically generating them) for the common case.

boot2docker (at least on macosx and windows) does have some support for volumes thru VBox guest addition, see boot2docker/boot2docker#534

It's exposed thru the -vbox-share flag: https://github.com/boot2docker/boot2docker-cli/blob/93908af574aa4fa11bf84990edde7c07e7d6ded5/virtualbox/machine.go#L142

-vbox-share defaults to the user directory. So, if the user's GOPATH is under their user directory (which is likely the case), they will never notice that the -v flag could be troublesome.

In my case, I use a remote machine as my Docker host. I had to share an fs between my laptop and the Docker host and set my GOPATH to the mount point.

Maybe, some documentation around -v would be good enough for now. It's so bad that it fails silently.

The doc was updated and the docker file was changed to require the mounted volume to be accessible.
Soon we will not depend on docker image for build as gomobile tool becomes available.
Duplicate of #9508