Actions
Bug #4060
closedTTCN3 test run failures on jenkins:
Start date:
06/13/2019
Due date:
% Done:
60%
Spec Reference:
Description
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: FAILUREThe odd parts about this are:
- 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.
Actions