As "docker kill" / "docker container kill" (alias) doesn't block until
the given container stops, make sure to always run "docker wait"
Add a new network_clean_remove_all_ttcn3 function and use it in the fr
related testsuites to ensure no network is running before the test
starts. We just had the situation where the network link between
gtp0-deb10fr (where these testsuites run exclusively, and only one at a
time) and the jenkins host went down. And so the clean up trap
apparently did not run and starting a new test fails as the old network
still exists and has the network devices attached.
Try multiple subnet numbers until successfully creating a network. This
way we can run the same ttcn3 testsuite multiple times in parallel
without conflicts (e.g. once against latest, once against nightly). Also
we don't need to make sure each new testsuite has a unique subnet
I've considered also adjusting network_bridge_create, but that gets used
exclusively by osmo-ran/jenkins.sh, a script which we don't actually run
in jenkins. It seems that in this script it makes more sense to not get
a random subnet number.
Other remotes are mirrors of gerrit one, which means there's some delay
between pushing some ref to the gerrit remote and having them available
in the mirrors.
Hence, it becomes annoying while developing and new stuff to test is
pushed. Let's simply use gerrit since it's the master remote.
Move cleaning up logic to clean_up(), so it runs as part of the
clean_up_trap if any command in the previous code fails.
For example, if the first docker container started properly, but the
second docker container failed to start: without this patch, it would
just stop the script without running the clean up code.
Revert the change of adding a --rm to the "docker run" commands done in
This script runs the containers in the background, waits until they are
done, copies the logs and then removes them afterwards.
+ docker kill jenkins-ttcn3-fr-test-384-frnet
+ docker logs --timestamps jenkins-ttcn3-fr-test-384-ttcn3-fr-test
Error: No such container: jenkins-ttcn3-fr-test-384-ttcn3-fr-test
Add "--rm" to each "docker run" command, so they don't continuously fill
up disk space.
Fix this even in the pipework script. We don't use the code path there,
but by always having --rm after "docker run" (same line or next line),
a new lint script in osmo-ci I8ab9c291504475d670bdefc50c4524c5bdd4c880
can help us avoid this in the future.
In ttcn3-ggsn-test/jenkins.sh, move one existing --rm in a later line
upwards so the linter can find it.
Related: SYS#5827, OS#5099
So far we were executing all our TTCN-3 tests from a container
image with Debian stretch (9) plus a custom more recent eclipse-titan
package from the osmocom feed.
Let's update the container base OS from stretch (9) to bullseye (11)
while using the same packaged eclipse-titan version (8.0.0) for running
the tests. So this should be a low-risk change, as titan runtime
I've executed all test suites locally and couldn't see any regressions.
Write a line like 'Misc_Helpers.mp_osmo_repo := "nightly"' into the
TTCN-3 config file (e.g. BSC_Tests.cfg), before starting the testsuite.
This allows executing different code paths in the tests based on the
+ docker container rm jenkins-ttcn3-fr-test-109-frnet jenkins-ttcn3-fr-test-109-ttcn3-fr-test
Error response from daemon: You cannot remove a running container 4f5ec7f412b2d37d00b2738b2bcddffada36efebfe7ce32ed196543ee436154e. Stop the container before attempting removal or force remove
Abort the script and trigger the clean up script, whenever any of the
commands below to prepare the testsuite are failing. This saves time
with figuring out why suddenly all or most tests are failing, and avoids
running the entire testsuite on jenkins if it's obviously not going to
Add set_clean_up_trap() in jenkins-common.sh and run it at the beginning
of the jenkins.sh files. Move the common clean up code from the end of
every jenkins.sh file into clean_up_common(), which gets called by the
trap. Add a custom clean_up() function to those jenkins.sh files that
need additional clean up.
Replace explicit container stop commands (for containers attached to the
docker network) with one call to network_clean() in clean_up_common(). It
kills all containers attached to the docker network.
The motivation for this change is the upcoming optional build of initrd
and kernel during ttcn3-ggsn-test/jenkins.sh. After building these, a
short smoke test will be performed to make sure we can boot the kernel
and initrd, before continuing to run the entire testsuite against it. If
building or the smoke test fails, we must do a proper clean up of the
network and fix permissions.
Allow jenkins to fetch the image from our private docker registry.
Outside of jenkins, the image is built locally just like before.
Move the shared pipework script to the base image, and call it in
ttcn3-docker-run.sh if WAIT_FOR_NETDEV is set. Use ttcn3-docker-run.sh
as entrypoint in both Dockerfiles and remove the custom entrypoint
scripts (which are the same as ttcn3-docker-run.sh now).
Move the git fetch/checkout code and make call to build the testsuite,
to debian-stretch-titan/ttcn3-docker-prepare.sh. In the next patch, I
will extend the script to update deps right before building too (e.g.
because OSMO_TTCN3_BRANCH changed).
Clone the osmo-ttcn3-hacks and all dependency repositories less often by
moving related commands to the shared debian-stretch-titan image.
Remove the 'git checkout -f -B master origin/master' line, because the
master branch is checked out by default.
While at it, move the shared "git config" commands too, and move them
before cloning the repositories, so they don't run again whenever the
deps change (logic to invalidate the cache if deps change will be added
in the next patch).
Remove leftover from old TTCN-3 build scripts, before refactoring ttcn3
Dockerfiles. This line has already been removed in 357ec806 from 2017 for
In osmo-ttcn3-hacks.git, this is only referenced in the obsolete
bin/install.script (looks like we could remove that, together with the
rest of the bin dir?).
On our deb10fr VMs we have the modified kernel HDLC module supporting
the frame relay MTU up to 1700 bytes, so let's extend our tests to cover
that. Mainline kernels only support 1500 bytes.
Depends: osmo-ttcn3-hacks.git I8e38ecf6b270c81bd73ee43b1fa0b259a999c14b
FRNET_Tests is not a test suite, but just a stub against which we
execute FR_Tests. Hence, we don't want it to generate a junit-xml,
as that doesn't contain any errors and only upsets our jenkins
test results analyzer, assuming the tests have failed.
Requires: osmo-ttcn3-hacks.git Id296e62fb86731492d42370173a48f217b2fbdc0