Create Dockerfiles that allow test execution

[smlambert]

Basing from those Dockerfiles that build openj9 (https://github.com/eclipse/openj9/tree/master/buildenv/docker), we should have matching set to allow test execution.

There are a few additional prereqs needed for test (see https://github.com/eclipse/openj9/blob/master/test/README.md for details on testing openj9).

[terryzuoty]

The dockerfile in link above doesn’t seem to build JDK or get a JDK, it simply setting up the environment. Maybe I am wrong if I miss something?

Do we want to integrate the test execution into the same dockerfile or have another dockerfile to execute tests?

[smlambert]

Separate dockerfiles for test, can be put in buildenv/docker/openj9test (or something similar that shadow existing ones). See the website instructions for the expected usage of the existing files, https://www.eclipse.org/openj9/oj9_build.html

[DanHeidinga]

+1 to putting the test-related docker files in the buildenv/docker directory. Does the test subdirectory need an openj9 prefix there or is test sufficient?

[smlambert]

buildenv/docker/test sounds good

we should update the webpage with additional information on these new dockerfiles once they are ready (as the instructions read right now, they imply that you would be able to move on the test step from using the existing dockerfiles, which is not the case).

[jdekonin]

Why would we not just add the additional requirements to the existing dockerfile(s)? or at a minimum built on top of the initial dockerfile?

[smlambert]

"Basing from those Dockerfiles that build openj9"

[mleipe]

Should we put the OpenJ9 Docker images onto Dockerhub such that the test Dockerfiles can be FROM them?

@mleipe #38

Yes, we shall put openj9 image on hub.docker.com

[terryzuoty]

Taking a second look at the Dockfiles in openj9/buildenv/docker/jdk9/<platform>/ubuntu16, I found that most of the executable dependencies have already been included in the Dockerfiles, only ant and ant-contrib are missing for test purpose.

After trying the whole building and testing process within Docker container, I think we need two separate tasks to solve two different Docker-related user scenarios.

Scenario 1: I want to run OpenJ9 tests against a downloaded OpenJ9 binary (OpenJ9 SDK). Or I just want to test my new test codes against a pre-built OpenJ9 SDK.

In this case, we just need a light weight Docker image which contains minimum dependencies for executing tests against OpenJ9 SDK. So Task 1 is to create a Dockerfile which should be independent from those Dockerfiles which build OpenJ9. It should be located in open9/buildenv/docker/test as Shelley and Dan mentioned.

Scenario 2: I want to build the OpenJ9 and also test it.

In this case, it will be convenient to build OpenJ9 and run tests in the same Docker image. So Task 2 is adding ant and ant-contrib into the Dockerfiles.
After adding ant and ant-contrib into the Dockerfiles and building it, (openj9/buildenv/docker/jdk9/<platform>/ubuntu16), the processing time of building Docker image increased less than 1 minutes.

In the contrast, building OpenJ9 and running tests in two different Docker images separate the clone-clone-make story, which we want to avoid. Also, the instructions in https://www.eclipse.org/openj9/oj9_build.html make it very difficult to build OpenJ9 and run tests in two separate Docker images. The openj9-openjdk-jdk9 repo is cloned within the Docker container which makes the OpenJ9 SDK built in this Docker image difficult to shared outside.

Summary:
a) we need to create an independent test-only Dockerfile for testing purpose
b) we also need to update those Dockerfiles which build the OpenJ9 to make them available to run tests in the same Docker image.
c) I also think we should update the instruction in https://www.eclipse.org/openj9/oj9_build.html. The openj9-openjdk-jdk9 repo should be cloned outside of Docker and mounted to a Docker container when needed. (https://forums.docker.com/t/best-practices-for-getting-code-into-a-container-git-clone-vs-copy-vs-data-container/4077 and http://blog.cloud66.com/how-to-get-code-into-a-docker-container/).