Add a bullseye based container that can be used instead of
debian-buster-jenkins-arm. The master-builds jenkins jobs will attempt
to use this jenkins job for the arm builds after setting the main
default image from debian-buster-jenkins to debian-bullseye-jenkins.
Related: OS#5949
Change-Id: I8e1741f86ffb8abd658d1e4e0415dfd11fb1a8a1
Prepare to let jenkins master-builds use debian-bullseye-jenkins
instead of debian-buster-jenkins. Add almost everything from the buster
Dockerfile to the bullseye Dockerfile that is not there, except for:
dh-systemd (not available in debian11)
Also add python2, as some projects still require it to run tests
(OS#5950).
Related: OS#5949
Change-Id: I51925d0ab9e5a779379efab59c381ef12fb60929
Add the ghostscript package, it contains ps2pdf which is now used in
osmo-gsm-manuals to shrink pdfs.
Related: SYS#6380
Change-Id: If7b30d0c948604211f4f5242aca8564c310a6ce3
As "docker kill" / "docker container kill" (alias) doesn't block until
the given container stops, make sure to always run "docker wait"
afterwards.
Closes: OS#5928
Change-Id: I0242ece96541d8036ebbf8b0f498ebf231db26b5
This Dockerfile allows building a given repo and branch of
titan.core.git which can then be used by any ttcn-*-test/ environment by
simply changing its Dockerfile "FROM" line from
$REGISTRY/$USER/debian-bullseye-titan to
$REGISTRY/$USER/debian-bullseye-titan-mater.
This is useful to debug or develop titan.core or test whether a given
testsuite works fine with a newer version of titan.core.
Change-Id: I19ee98a319ccad167d06c4f183fe80ecac909483
When running jenkins.sh as root or any other user with UID different
than UID=1000 of the 'osmocom' user we have in open5gs-{master,latest}
images, programs spawned by osmo-uecups-daemon (e.g. ping) may fail to
start. In such cases, osmo-uecups-daemon reports unexpected program
termination with exit code=512. This is happening because the
stdout and stderr of a spawned program are being redirected to
"$VOL_BASE_DIR/pgw-tester/TESTCASE.prog.std{out,err}", for which
the 'osmocom' user needs to have write permissions.
Change-Id: Icb6b30e618e290d974a919fef34c6b5cb7eeb648
Related: OS#5913
As stated in the ticket, both open5gs-{nrf,smf} daemons refuse to
start since build #326 because of the following error:
[sbi] ERROR: TLS enabled but no server key (../lib/sbi/context.c:186)
The problem is that the recent open5gs (v2.6.0-39-g22be888 at the
moment of writing) is attempting to employ TLS verification for SBI
even if it's not explicitly configured in the config files.
commit 05fbaf69587488e53b5e741a9ada9f9fa5749322
Author: Sukchan Lee <acetcom@gmail.com>
Date: Sat Feb 18 10:58:29 2023 +0900
[SBI] HTTP2-TLS verification - ConfFile Changed
Our config files are slightly outdated, so let's take a chance
to update them and specify the missing TLS params. Check out
open5gs-{nrf,smf,upf}.yaml from the latest git version.
The updated files are confirmed to work with both:
* latest release for Debian v2.5.8, and
* latest git version v2.6.0-39-g22be888.
Change-Id: I27adbab6a6b95ddf4c6d39803e4f7dd079f11a4c
Related: OS#5913
In ttcn3-pgw-test we're running open5gs-upfd as a non-root user.
We do have this user in open5gs-master, but not in open5gs-latest.
Change-Id: I9139fc52fa6973cf495559d3c4202d9f804a2079
Related: OS#5913
ping is needed for ttcn3-pgw-test. In the case of osmo-uecups-master
it's available from the parent $DISTRO-build image, but for the -latest
it needs to be installed by the inherited image itself.
Change-Id: Ia1b9124f09203c7dcf6d26dee78b09d5a139a04f
Related: OS#5913
The following warning message appears when running apt-key:
apt-key is deprecated. Manage keyring files in trusted.gpg.d instead
The apt-key man page mentions that the "use of apt-key is deprecated,
except for the use of apt-key del in maintainer scripts to remove
existing keys from the main keyring". What's more, "apt-key will last
be available in Debian 11 and Ubuntu 22.04".
Additionally, while the deprecation message says to "manage keyring
files in trusted.gpg.d instead", the Debian wiki states otherwise.
It's recommended to store the keys in /usr/share/keyrings instead,
and then use the 'signed-by' option to reference them.
ee284d5917
Change-Id: I1cae4f49e72f5e4f9d703cdb8f6d117e18e3567c
Give OsmoBSC time to connect to OsmoSTP, so BSSMAP RESET from the
testsuite doesn't fail in OsmoSTP with:
MTP-TRANSFER.req for DPC 187: no route!
Without this patch, it would fail every other time on my system when
only having one test enabled in BSC_Tests.cfg.
Change-Id: Ic7f80bdfe2fe58e93c2f2e3baa6d7645fcdc3062
Add a parameter that can be used to reproduce the failure locally with
the last list from jenkins, without having SSH set up to download the
list of existing tarballs.
Change-Id: I9af310c24aa65c21cc4bd365d3df7804cba02df7
Probably copy pasted from another script, doesn't make much sense here
since only the release tarballs are built. Nothing gets compiled here,
the variable was not used.
Change-Id: Ie74ee6976759f9634503b21e964e93efcc925679
Run configure with the --with-mstrx argument, so LIBTRXCON_DIR is not
pointing at an empty directory.
Fix for:
make[2]: Entering directory '/build/_temp/repos/osmo-trx/osmocom-bb'
make[2]: *** No rule to make target 'distdir'. Stop.
Change-Id: I2f067409f98119d4e35cf86cc2c816fc3c19e3f5
We're not *building* anything for the open5gs-latest, but simply
downloading and installing DEBs from Sukchan's opensuse.org repo.
Change-Id: Iec7ccab28c37d274a731e08a2f893ec0514c1068
Fixes: 62ac21133a
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.
Related: OS#5802
Change-Id: I6a9464a11edcba978be08764bec9de19760a5c77
Add a minimal image to use on the raspberry pis, so it doesn't need to
spend 1-2 hours building debian-buster-jenkins on the raspberry pis,
full of things we don't actually use there.
I've verified that osmo-bts, osmo-pcu, osmo-trx build with this image
(the only projects which we build on the rpis).
Related: OS#5863
Change-Id: I4fb4b48b233acaef815c4c27ec6f17f12cfe836b
Make ttcn3-bts-test work as expected again by replacing the subnets
hardcoded in the confmerge files and Makefile.
Related: OS#5802
Change-Id: I733619f80b4e2456da070649634d3c942bb6d95f
Make ccache available inside debian-buster-jenkins. An upcoming osmo-ci
patch will make use of it in gerrit-verification and master jobs. With
this docker-playground patch alone it's not used yet since
/usr/lib/ccache is not in the default PATH.
Related: OS#5848
Change-Id: I164c7835f99436e8d768a864f36118eaf799d109
As we run more testsuites in parallel, the load was higher and so this
timeout was reached.
Related: OS#5802
Change-Id: I823010106a99a4906e32198ed42b36f9fe662c4e
Put the current SUBNET into NET_NAME, not the previous one. Without this
patch it works too, but this makes more sense.
Related: OS#5802
Change-Id: I6c90505fd6c0ba62244ff67709b0bf31bf44b449
Fix the bug that running a test twice on the same host results in the
second test stopping the containers and network of the first test:
* Have the subnet name in the network name, so there's no collision of
network names when cleaning up the network.
* Don't clean up the network when creating a new network. Rely on the
clean up trap to clean up the network instead.
* Don't set NET_NAME when sourcing jenkins-common.sh anymore, as
network_create will set it. There's also network_bridge_create, which
only gets used by osmo-ran (which we don't run in jenkins). Add a
check to this function to ensure NET_NAME is set before calling it,
which osmo-ran is already doing.
Related: OS#5802
Change-Id: Ifcd384272c56d585e220e2588f2186dc110902ed
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
number anymore.
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.
Related: OS#5802
Change-Id: I57152b08ef0f38e17e7019a8df032189b03f56cf
Use the SUBNET variable instead of hardcoding it in some places. Split
commands across multiple lines while at it to improve readability.
Related: OS#5802
Change-Id: I08f83089ef97f5f92d4bbfa5743301e7375e9f0f
* Do not clone using deprecated git://, use https:// instead.
* Clone from the main repo gerrit.osmocom.org (if possible).
* Use the gitiles plugin to fetch the last commit from Gerrit.
Change-Id: I204fa6e3e3ebbdb8732393b897fca35659d61ae8
Add a $SUBNET parameter and use it throughout the script, similar to
other ttcn3-*/jenkins.sh scripts. This is in preparation for figuring
out a free network in network_create() automatically in a future patch.
Related: OS#5802
Change-Id: I3bda4bd7280469ad5ee02104295134a2e0b768e3
Prepare for a future patch where a free subnet will be figured out
automatically instead of having a hardcoded one, by moving
initrd-ggsn.sh to $VOL_BASE_DIR as the subnet will be replaced in files
in this directory.
Related: OS#5802
Change-Id: Ie4f35b77a2bff20f2a0479890a429754768cafd2
Use 'set +x' before echo, so messages are not printed twice and the
output becomes more readable.
Example:
+ echo Creating network ttcn3-bts-test
Creating network ttcn3-bts-test
Related: OS#5802
Change-Id: I213cb80bd1d9401281ae1fb7394b2319453550dd
Remove the docker containers for repo-install-test, as it is now running
in qemu + kvm.
Related: OS#5365
Depends: osmo-ci Ie7f1bccb05779cb3614016c0b965b810bbb1471b
Change-Id: Ic40fddcc6b30318b3a6e63fe99b010939b95be25
Don't use the "operstate" sysfs attribute to determine if an interface
is "up", use the actual UP-flag (0x01) in the "flags" sysfs attribute.
The "operstate" attribute may at least occasionally be "unknown" and
remain in that state (causing jenkins jobs to wait indefinitely), while
the flags (which we don't look at before this patch) indicates it is "up".
This is a fixup to the below commit:
commit d2014603a7
Author: Harald Welte <laforge@osmocom.org>
Date: Wed Feb 3 22:05:43 2021 +0100
debian-stretch-titan: Wait for interface to be _up_ not just its existance
Change-Id: Ib5c3bbe470ce874217437c2518df5ae07f0d8301
Closes: OS#5803
Run all commands inside the docker containers as a user with the same
UID as on the host system, not as root. This is a good idea in general
and also fixes permission problems when jenkins tries to wipe the
workspace.
Related: OS#5793
Change-Id: I0d949e5ab4b1a709d18a316def0a98c3b244457e
Don't fail if no tarball was generated and therefore the
_release_tarballs directory does not exist.
Related: OS#5793
Change-Id: Ib7c551e5376776eb267140bc4b897d5bb1634cbc
Previously this job relied on always running on the same jenkins node,
and having the previously built release tarballs in a workspace
directory that does not get removed. It would only skip building a
release tarball if the file already exists locally.
As part of OS#5793 this job needs to be moved away from that jenkins
node. When trying to run the job on a different node, it will build all
release tarballs again which takes unnecessarsily long and actually
fails on libosmocore-0.9.4 due to a missing python2.
This probably happens because the job was refactored at some point and I
didn't realize that the python2 dep is now missing as the previous
tarballs existed.
In general it doesn't make much sense to build previous release tarballs
again and to always keep the legacy environments around for that. Change
the code to check if a tarball exists on the server, and skip building
the tarball in that case.
Related: OS#5793
Related: https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/Osmocom-release-tarballs/1281/console
Change-Id: I4b8c149c9cdbe7c613eea5d9be15794de5e5ddce
Prepare to use ssh inside the docker container to check if tarballs
already exist, see the next patch.
Remove the '' around UserKnownHostsFile as using SSH_COMMAND in the next
patch without rsync fails otherwise with:
command-line: line 0: Bad configuration option: 'userknownhostsfile
Change-Id: I6dfe5d587d05063c6cf2c9ec683e7b7e499b79c1
