Miscellaneous Projects » Core testing infrastructure

The typical docker files for packaging one of our test suites looks like this:

ARG     USER
FROM    $USER/debian-stretch-titan

RUN     git clone git://git.osmocom.org/osmo-ttcn3-hacks.git

RUN     cd osmo-ttcn3-hacks && \
        git checkout -f -B master origin/master && \
        make deps

ARG     OSMO_TTCN3_BRANCH="master" 

ADD     http://git.osmocom.org/osmo-ttcn3-hacks/patch?h=$OSMO_TTCN3_BRANCH /tmp/commit
RUN     cd osmo-ttcn3-hacks && \
        git fetch && \
        git checkout $OSMO_TTCN3_BRANCH && \
        (git symbolic-ref -q HEAD && git reset --hard origin/$OSMO_TTCN3_BRANCH || exit 1); \
        git rev-parse --abbrev-ref HEAD && git rev-parse HEAD && \
        make ggsn_tests

We just ran into massive build failures, as an update to Makefile/deps does not trigger re-build of the Docker images. The "ADD" of the http;//git.osmocom.org URL is done only after the "build dependencies step. So no matter what one commits to deps/Makefile, the container will always start at that "ADD", keeping the old dependencies without any way to force a related rebuild other than manually logging into all build slaves and deleting the respective images (basically all of them).

Now we could simply move that ADD line up in all dockerfiles, but I think the solution is actually rather to include the 'deps' in the debian-stretch-titan image altogether. We could then (hopefully)

• use jenkins to trigger a build of that image whenever there's a change in the deps/ subdirectory of osmo-ttcn3-hacks.git only
• push that image to registry.osmocom.org
• make all other build jobs use that image from the registry, rather than rebuilding from scratch

This approach has the added benefit of reducing build times (cloning dozens of 'deps' git repositories on each build of each slave) and of course reduce traffic and unneccessary load on the git servers.