Miscellaneous Projects » Core testing infrastructure

We quite frequently see tests fail like this:

+ collect_logs
+ fix_perms
+ docker_images_require debian-stretch-build
+ local from_line
+ local pull_arg
+ [ -z  ]
+ pull_arg=--pull
+ grep ^FROM ../debian-stretch-build/Dockerfile
+ from_line=FROM debian:stretch
+ echo FROM debian:stretch
+ grep -q $USER
+ echo Building image: debian-stretch-build (export NO_DOCKER_IMAGE_BUILD=1 to prevent this)
Building image: debian-stretch-build (export NO_DOCKER_IMAGE_BUILD=1 to prevent this)
+ PULL=--pull make -C ../debian-stretch-build
make: Entering directory '/home/osmocom-build/jenkins/workspace/ttcn3-bscnat-test/debian-stretch-build'
docker build --build-arg USER=osmocom-build --build-arg OSMO_TTCN3_BRANCH=master \
    --build-arg OSMO_BSC_BRANCH=master \
    --build-arg OSMO_BTS_BRANCH=master \
    --build-arg OSMO_GGSN_BRANCH=master \
    --build-arg OSMO_HLR_BRANCH=master \
    --build-arg OSMO_IUH_BRANCH=master \
    --build-arg OSMO_MGW_BRANCH=master \
    --build-arg OSMO_MSC_BRANCH=master \
    --build-arg OSMO_NITB_BRANCH=master \
    --build-arg OSMO_PCU_BRANCH=master \
    --build-arg OSMO_SGSN_BRANCH=master \
    --build-arg OSMO_SIP_BRANCH=master \
    --build-arg OSMO_STP_BRANCH=master \
    --pull -t docker.io/osmocom-build/debian-stretch-build:latest .
Sending build context to Docker daemon  4.608kB

Step 1/3 : FROM debian:stretch
Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on 192.168.111.1:53: read udp 192.168.111.6:42724->192.168.111.1:53: i/o timeout
../make/Makefile:56: recipe for target 'docker-build' failed
make: *** [docker-build] Error 1
make: Leaving directory '/home/osmocom-build/jenkins/workspace/ttcn3-bscnat-test/debian-stretch-build'
+ exit 1
Build step 'Execute shell' marked build as failure
Recording test results
Sending e-mails to: laforge@gnumonks.org
Archiving artifacts
Finished: FAILURE

• why is "192.168.111.1:53" used as DNS server despite the underlying operating system using "real" DNS server IP addresses (213.133.98.98, 213.133.98.99, 213.133.98.100)? Even if I manually start a container with "docker run --rm -it busybox", its /etc/resolv.conf are set "correct", i.e. don't show any 192.168.111.1 IP
• why are we rebuilding that container image during the "collect logs" step? This means that we have invested significant time to execute an entire test suite, and then throw away all those results just because a reandom image for collecting log files hasn't been up to date.