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.
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.
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?).
Testing FR support in osmo-gbproxy is a bit more complicated
as it involves the "hdlc" net-devices privded by the hdlc_fr.ko
So we need to
* run on a host with actual hdlc net-devices (e.g. dahdi_dyamic_loc)
* move those net-devices into the containers after starting them
* wait for the net-devices to appear in the containers before starting
either gbproxy or the test suite