Update ADD handling in Dockerfiles and test bundle creation

blimp/engine/testing/Dockerfile

 # This Dockerfile is used to build a filesystem environment containing
 # binaries and required files for Blimp Engine test and tests for dependencies
 # of Blimp Engine. It is built on the same base image that is used to run the
 # Engine itself.
 FROM base:latest
 
-RUN mkdir -p /out/test/
+RUN mkdir -p /test/out/test
+RUN mkdir /test/base /test/blimp /test/net
 
-# The glob below expands to all files, but does not add directories
-# recursively.
+RUN useradd -ms /bin/bash blimp_user
+
+# Ensure directories end up at expected levels.
+# Docker copies directory CONTENTS rather than the directories themselves.

[Jess, 2016/07/15 20:26:59]

Note for reviewers. This is the point of confusion that existed previously for
the Dockerfiles.

Documentation https://docs.docker.com/engine/reference/builder/#/add

Each <src> may contain wildcards and matching will be done using Go’s
filepath.Match rules. 
...
If <src> is a directory, the entire contents of the directory are copied,
including filesystem metadata.
Note: The directory itself is not copied, just its contents.

[maniscalco, 2016/07/15 20:54:01]

I want to understand what's the desired directory structure inside the docker
image.

Do you really want sub-directories for net, base, etc.?

Is seems like the simplest thing would be for everything in the tarball to end
up in /test, right?  I think you can achieve that with "ADD . /test/".  For
example:

$ cat Dockerfile 
FROM ubuntu:trusty
RUN mkdir /foo
ADD . /foo/
ENTRYPOINT [ "/bin/bash" ]


$ tar czf ../files.tgz ./ && cd .. && docker build - < files.tgz
Sending build context to Docker daemon 3.072 kB
Step 1 : FROM ubuntu:trusty
 ---> f429597fd334
Step 2 : RUN mkdir /foo
 ---> Using cache
 ---> 552fa8b209da
Step 3 : ADD . /foo/
 ---> Using cache
 ---> 830b6f8538a2
Step 4 : ENTRYPOINT /bin/bash
 ---> Using cache
 ---> fed1e3d7fc92
Successfully built fed1e3d7fc92

$ docker run -ti fed1e3d7fc92
root@6132083cf5d7:/# ls -laFR /foo
/foo:
total 16
drwxr-xr-x  3 root root 4096 Jul 15 20:48 ./
drwxr-xr-x 35 root root 4096 Jul 15 20:50 ../
-rw-r-----  1 root root   73 Jul 15 20:47 Dockerfile
drwxr-x---  2 root root 4096 Jul 15 20:34 one/

/foo/one:
total 8
drwxr-x--- 2 root root 4096 Jul 15 20:34 ./
drwxr-xr-x 3 root root 4096 Jul 15 20:48 ../
-rw-r----- 1 root root    0 Jul 15 20:34 file
root@6132083cf5d7:/# 

[Sriram, 2016/07/15 22:23:09]

+1 asked the same question offline to Jess. I don't think we want a subdirectory
for each of the test type but just one out/test.

[Jess, 2016/07/15 22:45:08]

Resolved issues from here:
Use ADD . /blimp for src directory deps.

Resolved issues discussed offline:
Update base directory name from "test" to "blimp"

Issues from offline still to be addressed: representing the build directory
structure in the tarball itself so we don't have to fix it using this
Dockerfile.

I'll send a mail when that last one is in place, but wanted to capture the
offline and Dockerfile changes immediately

+ADD base /test/base
+ADD blimp /test/blimp
+ADD net /test/net
+
 # Test binaries assume src directory is 2 levels down. While this behavior can
 # be changed with flags, the directory structure is set up to minimize
 # potential problems with initial integration.
-ADD * /out/test/
+# The source glob here captures test binaries, required shared binaries (.so)
+# and .dat files at the bundle root without recopying directory contents.
+ADD *tests *.* /test/out/test/
 
-RUN chown -R blimp_user /out/test/
+RUN chown -R blimp_user /test
 
 USER blimp_user