Compile inside Docker container without huge container sizes

Question

I'm creating an auto-testing service for my university. I need to take student code, put it into the project directory, and run tests.

This needs to be done for multiple different languages in an extensible way.

My initial plan:

• Have a "base image" for each language (i.e. install the language runtime on buildpack-deps:stretch)
• Take user files & pre-made project structure
• Put user files into the correct location in the project
• Build an image of the project extending the base image
• Run the container. It will compile the project and run tests.
• Save test results to the database, stop & delete the image
• Rinse repeat for every submission

When testing manually, the image sizes are huge! Almost 1.5GB in size! I'm installing the runtime for one language, and I was testing with Hello World - so the project wasn't big either.

This "works", but feels very inefficient. I'm also very new to Docker – is there a better way to do this?

Cheers

Answer 1

In this specific application, I'd probably compile the program inside a container and not build an image out of it (since you're throwing it away immediately, and the compilation and testing is the important part and, unusually, you don't need the built program for anything after that).

If you assume that the input file gets into the container somehow, then you can write a script that does the building and testing:

#!/bin/sh
cd /project/src/student
tar xzf "/app/$1"
cd ../..
make
...
curl ???  # send the test results somewhere

Then your Dockerfile just builds this into an image, without any specific student code in it

FROM buildpack-deps:stretch
RUN apt-get update && apt-get install ...
RUN adduser user
COPY build_and_test.sh /usr/local/bin
USER user
ADD project-structure.tar.gz /project

Then when you actually go to run it, you can use the docker run -v option to inject the submitted code.

docker run --rm -v $HOME/submissions:/app theimage \
  build_and_test.sh student_name.tar.gz

In your original solution, note that the biggest things are likely to be the language runtime, C toolchain, and associated header files, and so while you get an apparently huge image, all of these things come from layers in the base image and so are shared across the individual builds (it's not taking up quite as much space as you think).