Add a new jenkins job to notify us about new versions of Debian,
Raspbian and Ubuntu becoming available in the openSUSE OBS. This allows
us to consistently follow along and make the repositories available in
the Osmocom OBS. I've decided to check the openSUSE OBS instead of
checking somewhere upstream, because it takes time between a new
release of a distribution and the version becoming available in
openSUSE OBS, and we have another job that syncs the configuration with
that OBS instance.
Related: OS#6163
Change-Id: I0abc49a95197da55f7d83ed4fd1c4ebb6bd14b1e
osmo-upf currently can't build against debian 10, as the required
libnftables-dev version there is too low and we don't provide a backport
for it. As discussed, disable it for debian 10.
Adjust CI to build against debian 11 instead (in addition to the usual
almalinux 8, debian 12).
Change-Id: I63798d451b66bf728b58b02414c1a44f6156b356
Adjust all jobs in the gerrit verifications pipeline to use the same
parameters from a new include file, to prevent undefined parameter
warnings in the log.
Fixes: OS#6261
Change-Id: Iadc5cd8996eb4ed86634ceb35829a3e9239e598d
Add the erlang projects found in gerrit-verifications to master-builds
too, as we have it with most other Osmocom projects.
Change-Id: I6cf5a3c1e52ee73ad63eb2d7d5b1af19a9809026
Make it easier to copy entries from gerrit-verifications.yml to
master-builds.yml by using the same url schema in both.
Change-Id: Ibe992dd8027a8b8df8623abc57a590972443449f
Run contrib/jenkins.sh of osmo-python-tests once a day from master too,
not only from gerrit verifications.
Change-Id: I164553d0948549d60c45b8840716c608463dc486
Ensure we trigger building new OBS packages first, then wait plenty of
time until the binary packages are available (and run jobs in the
meantime that don't need them), and only after that we run the jobs
that need the binary packages.
Otherwise TTCN3 jobs may test the packages from the previous day, and
some jobs may fail completely due to packages not being completely built
yet. For example, yesterday the new Osmocom CNI releases were tagged,
which means the :latest packages also need to be rebuilt (-> building
all OBS packages takes longer). The osmocom-release-manuals and
-tarballs jobs failed, because the new binary packages were not
available yet when they ran.
Change all timers to the format "H 20 * * *" to have a deterministic
hour and semi-random minute based on the job name.
Change-Id: Ib68f9a78bae27a63706a8c95715bf6a244b7bf1d
Fix running the job multiple times in a row. As the master jobs don't
wipe the git repositories, we need to remove the osmo-ci dir first
before attempting another shallow clone.
Fixes: 451cbe7d ("jobs/master-builds: add xgoldmon")
Change-Id: I877944dbca9d1c3ca57b05e947ba9b3506971bdc
Replace the legacy osmo-ir77 job (not done with jenkins-job-builder)
with a new master-osmo-ir77 job that works just like the other master
jobs:
- build in docker
- have build commands in contrib/jenkins.sh
Depends: satellite/osmo-ir77#1
Change-Id: I45034e4ed9ed8ad5683ac2de24521649f138b41c
Replace the legacy SIMtrace job (not done with jenkins-job-builder) with
a new master-simtrace job that works just like the other master jobs:
- build in docker
- have build commands in contrib/jenkins.sh
Set the same notification mails as for simtrace2.
Depends: sim-card/simtrace#1
Change-Id: I0980ceafa4d1187630b75b45b01b538c750021bb
Replace the legacy xgoldmon job (not done with jenkins-job-builder) with
a new master-xgoldmon job that works more similar to other master jobs:
- build in docker
- have build commands in a jenkins.sh script
Put the jenkins.sh script into osmo-ci, as the upstream repository is
outside of Osmocom infrastructure.
The motivation for this change is, that the current xgoldmon job is
failing since libosmocore depends on liburing by default. This uncovered
that the job is still running outside of docker, where the dependency
has already been added. The following patches will modernize other jobs
which have the same problem.
Change-Id: Ice5704eb12f3c3a777961bc18a55fac63df80fd6
Fix for:
./jenkins.sh: line 35: /home/build/osmo-ci/coverity/get_token.sh: No such file or directory
Fixes: 56bc906e ("coverity: run inside docker")
Change-Id: I87fadd2dffcfaa04eaa942dfb8a496334cb722d5
Run the coverity job inside docker, so all depends are available (fixes
that it currently fails because liburing isn't available for
libosmocore).
Depends: docker-playground I25862a7e3c8a73e13fd4a9237ab57500d8dfc95c
Change-Id: I5cfdb6b2e12e176ff6d6ed6c1b8505d7694993f9
Run this job inside docker, so all depends are available (fixes that
it currently fails because liburing isn't available for libosmocore).
Change-Id: I5a8243b3096dba8f94f715413c84683c7495777c
Run the osmocom-api job inside docker, so all depends are available
(fixes that it currently fails because liburing isn't available for
libosmocore).
Use the contrib/known_hosts file, instead of writing an own copy during
the job.
Change-Id: I6e831c71c4c88772c3e4232fcb1a9e2c1c73d997
Don't try to build the debian package for debian 10. It fails as rebar3
is not in debian 10. Test the build for debian 11 and 12, which is what
we build the package for on obs.osmocom.org.
Change-Id: Id01b466f1bacc9cbb8e835f69da765f5fdccfdc2
Rewrite the osmocom-release-manuals script (previous version is in
docker-playground Ic35a28a386170b85d32aab8f2bd33e48e6d45392):
* Instead of using a separate docker container for this, that also lists
all dependencies for all packages (as needed to pass ./configure), use
debian-bookworm-build and install missing packages at time of
generating the tarballs with "apt-get build-dep". Missing dependencies
are typically other Osmocom libraries.
* This allows removing the debian 11 based release-tarball-build-dist
container. As the script doesn't depend on a separate docker container
anymore, move it to osmo-ci.git.
* Make it similar to scripts/manuals/publish-manuals-for-tags.sh, so it
is easier to maintain both.
Related: OS#6057
Change-Id: I9f8b671b9780da500637a64fc4dbc72b450f9d11
Fix the failing osmo-gsm-tester_virtual job by building the docker image
it depends on first, debian-buster-jenkins.
We are migrating most of the CI infrastructure away from old debian
versions to debian 12, but this is not possible here as explained in
OS#6126.
Related: OS#6126
Change-Id: I5f7468a402d82e3b6ee03b4f792ae7e3aae3942b
openbsc, osmo-e1-recorder, osmo-smlc have been adjusted to not require
python2 anymore. Let them use debian 12 for building.
Closes: OS#5950
Change-Id: I1d9204b5b59866fa79839221bb47ec4f7206a982
Build packages in CI for the oldest and newest debian release, for which
we provide binary packages in the Osmocom OBS repositories.
See "jobs: master/gerrit: use debian bookworm (12)" for reasoning:
I079e55a1325083714c8d39f922b2563e843fc0bc
Related: OS#6057
Change-Id: I959b466865bd327cc72cde4a1763ac13c2c2d797
Don't build libusrp for centos8/almalinux. libusrp does have a .spec.in
file, but it needs SDCC for the build and SDCC is not available there.
In theory we could build the rpm in CI for opensuse tumbleweed, but it
requires adding support for building for opensuse in
scripts/obs/data/build_binpkg.Dockerfile and
scripts/obs/data/build_rpm.sh first, and since it works quite
differently than centos8 and libusrp changes rarely (last code change in
2021) I've decided to not do that now.
Fixes: OS#5898
Change-Id: If61765fe628321cae004307f4845d8927a1c7019
Make it possible to set a list of distributions to check in
gerrit-verifications.yml instead of only having one boolean for testing
two hardcoded rpm and deb distributions.
Change-Id: I59487e3dc2f55057de1b6a322f088fff0d18654c
* Deduplicate the code to run a job by moving it to a function.
* Print the status of jobs right after they finished, instead of waiting
until all jobs are done
* Make the status print messages more readable
Change-Id: I641a5b483721ce2bbf21bd61d8f4e83faf94ac24
The asn1c code does not follow our coding guidelines, and in the
interest of keeping it closer to upstream it does not make sense to
reformat it.
Change-Id: Iae97d8997b576e43c9a73dfcc61a9260f875310f
Add parameters to set the osmo-ci and docker-playground branch. I'm
using this to test the debian 12 based containers before merging the
changes to master.
Related: OS#6057
Change-Id: I62265300048031cbb65e997b921373894500233f
Upgrade from debian 11 for master and debian 10 for gerrit
verifications to using debian 12 for both.
Previously we intentionally built against the older debian 10 version
to ensure that our programs still build there. However it is easier to
maintain the docker containers if we just use the most recent debian
version for both and it makes the build environment more consistent - if
a patch passes in gerrit verifications, we expect it to pass in master
builds as well. And the other way around, I can just run CI of all
master jobs when developing a change and assume that if they pass,
gerrit verifications will run as well.
As long as we provide binary packages in OBS for debian 11, 10, ... we
will still notice if a build breaks on an older debian release. I think
this is good enough given that it will probably not happen that often,
but if we decide that we really want to ensure it still builds on older
distros at gerrit-verification time then the more suitable place to add
this would be in the deb-build verification test. It is more
maintainable there, because the dependencies just get installed from the
debian/control file, no need to add all of them to a docker container
beforehand.
The new container is debian-bookworm-build, see the docker-playground
commit for reasoning why it is not debian-bookworm-jenkins.
Related: OS#6057
Depends: docker-playground I49aaf62b5b97775f923453611df3b91354a640a0
Change-Id: I079e55a1325083714c8d39f922b2563e843fc0bc
* we never really wanted to build against fixed tags but branches, i.e.
"the latest tag within a given stable series", so switch from a fixed
tag like "v5.10" in torvalds/linux.git to "linux-5.10.y" in stable/linux.git
* we also want to build against 6.1.y, as that is what upcoming Debian
bookworm will ship
Change-Id: I60aa61cb5020c9ce50126b048a0fa546a535236f
* we never really wanted to build against fixed tags but branches, i.e.
"the latest tag within a given stable series", so switch from a fixed
tag like "v5.10" in torvalds/linux.git to "linux-5.10.y" in stable/linux.git
* we also want to build against 6.1.y, as that is what upcoming Debian
bookworm will ship
Change-Id: Ibc0527a6f7d11c4f99c19e73c948b9baacd4e5a2
Upload workspace.tar.xz if it was created by osmo-bsc or osmo-msc, after
the testsuite failed. This should help with figuring out why sometimes
we get a coredump.
Related: OS#5665
Change-Id: I40b738558b83efc9256e5d5c48ffce42ddce9a8a
Do not run struct_endianness.py from libosmocore.git on osmo-ci.git, as
it doesn't contain C code.
Change-Id: Ib9a2ed2ce02a171f0bdca56728f8cdabf8f4cd1f
Build the manuals with --enable-iu for osmo-msc and osmo-sgsn, so we
don't miss IU-related VTY commands in the manuals.
As of writing, osmo-sgsn includes cs7-instance-iu only if building with
--enable-iu. osmo-msc includes it regardless of the build flag (and
returns an error if trying to use the command if built without IU
support). Build the manuals with --enable-iu for both for consistency,
and just in case we decide to change this behavior / add more commands.
Related: OS#6013
Change-Id: Ib9c47796b582add90ef72376b4c0368a29d89b15
Build osmo-hnbgw with and without PFCP. Build the manuals with PFCP, so
it includes the additional VTY commands.
Related: OS#6013
Change-Id: I4a4e25e0c179c0d408c3728a28eb75bbfa086f48
Oliver Smith
Pau Espin
Harald Welte
Neels Hofmeyr