One thing that some people do is run init inside a docker container. This does work, but if you can design a system that doesn't need that, the community leans towards not running init/ssh/etc.
Here's how I would approach using docker for CI of say, a Python application:
1) My CI agent checks out the code as normal
2) my dockerfile gets me an image with Python installed and my projects requirements setup (
pip install -r requirements.txt)
3) I set up a volume for the container that is the working directory of my checked out project on the CI host.
4) I fire up the container as many times as I need to run my tests.
- Any outputted files (like a junit-formatted unit test xml report) will stay on disk and be available to CI after the process completes and the container exits.
- I still get return status information if I do not run my containers in daemon mode (don't use
- I still get stdout output from the processes that I run in the containers when not using
- I can even connect up input with the
-i option if I need to pipe anything in from outside the container to the process that I run containerized.
So for a normal python project, my CI system might do the following commands (more or less):
git clone git://foo/bar/path/to/project.git
docker build -t project_image .
docker run -v /path/to/ci/checkout/project:/project /bin/bash -c 'cd /project && python setup.py test'
echo $? # should be 0 when tests pass
docker run -v /path/to/ci/checkout/project:/project /bin/bash -c 'cd /project && python setup.py build'
echo $? # should be 0 when build successful
ls dist/project-0.1-py2.7.egg # this should exist because of the volumes
so I ran two containers, and used volumes in this CI setup to run two commands separately.
It isn't quite exactly what you were after in your original question, but it is a real workflow that I have used for my CI projects in the past. I do get the advantages of fast build times thanks to using a dockerfile and having the intermediate images cached on the CI server. I can also swap in other dockerfiles if I want to test different things-- python 2.6, 2.7, and 3.4 for example. Maybe I throw in Jython and pypi too.
Hopefully this is helpful!