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 part of the jenkins job that generates documentation doesn't run on
simtester anymore, so no need to install these dependencies anymore.
Related: pysim.git I5245c529db729e209d78a02ab9c917a90d0e0206
Related: OS#5497
Change-Id: I0dc1c9f9fc87ae1832d836d98f06e798b51c7e2e
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
Add a workaround that upgrades the osmocom-nightly package before
installing build dependencies for the given package.
This is not very elegant, it would make more sense if the docker image
we use here did not have the nightly Osmocom repository configured in
the first place (as this job is about creating manuals for tagged
releases). But the image is used by jenkins build verification too and I
don't think it's a good use of time to change this right now.
Fix for:
+ apt-get -y build-dep /build
Note, using directory '/build' to get the build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
osmo-gsm-manuals-dev : Depends: osmocom-nightly (= 202305300026) but 202305290026 is to be installed
Change-Id: If28a34d3e5b07216c5310b19623fcc42692f65c3
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
The yum-builddep command already has a mechanism to update the package
index data if the last update (when the docker image was built) was some
time ago. However when the packages we use happened to be updated in
that timeframe, the indexes are not updated and attempting to download
them leads to 404 errors. Force refresh all package indexes to avoid
this.
Fixes: OS#6038
Change-Id: I6e2592466b6190782cdd93e00b3d5020fd665372
Use the optimization of only installing osmo-gsm-manuals-dev and all its
dependencies once not only with debian, but also with ubuntu.
Change-Id: Ic9fef9f10b4384538e7a73479bf57a9b737a9a55
Make it possible to configure a different feed than master inside the
docker container that gets used to build the packages. This way we can
build ubuntu packages against nightly.
We don't build the Osmocom packages in the master feed for Ubuntu as we
rarely have a build error that only happens on ubuntu. With this patch,
it can be easily reproduced if it happens.
Change-Id: Ibc27459815f26e8c691c83fe594ff84962b991f5
Make it obvious that the argument passed to --docker is the Linux
distribution that will be used.
$ ./build_binpkg.py -h
usage: build_binpkg.py [-h] [-d [DISTRO]] [-j JOBS] [-r] [-v] package
Change-Id: Ibf6f1a8fce7fd13795f1c25c75e14fb9eb8aa2b6
Adjust the code so one can pass all versions, instead of hardcoding
only debian:11, ubuntu:22.04, almalinux:8. I'll use this for
reproducing a build error that happens on e.g. ubuntu:18.04.
Change-Id: Id85f5b67d144dc178d3fb23ff8e533a671473363
Do not run struct_endianness.py from libosmocore.git on osmo-ci.git, as
it doesn't contain C code.
Change-Id: Ib9a2ed2ce02a171f0bdca56728f8cdabf8f4cd1f
Enable configure options to build manuals with all VTY commands in the
script that builds manuals for tagged releases.
Related: OS#6013
Change-Id: I9685857348e3b38f13acc1429c7a49fb9e5d92f3
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
Having the OBS URL at the end of the jenkins job was useful when we were
uploading to obs.osmocom.org and build.opensuse.org at the same time
during the transitional phase. Remove the URL from the job name as this
isn't the case anymore, and so the jobs look consistent with new
Osmocom_OBS jobs.
Change-Id: I460f9e6a508421773e300eee6c5c5654e5760cdb
Add this alias to use all Osmocom packages, but no the misc packages
that would also be selected if not specifying the packages argument at
all (limesuite, neocon, open5gs).
This will be used for building packages from the rhizomatica branches,
so we don't check the git repositories of these misc projects for the
git branches.
Related: OS#5981
Change-Id: I4265f43408bc21ac8765449d6766381c75cafe86
Add a new argument to delete packages from OBS if the git branch does
not exist anymore, but the packages still exists in OBS.
Related: OS#5981
Change-Id: Ib5ccf93a5a0cf8981fc35976bb9e0d3a29721b8d
Prepare to create new feeds for the rhizomatica/testing and
rhizomatica/production branches, which will be based on osmocom:latest.
They will depend on osmocom-latest (the "conflict package"/meta
package), even though their feed name is not latest.
Related: OS#5981
Change-Id: I58e33bb003e2a4af9e9a7b53e5f79a91c3b541eb
Set the proper https://obs.osmocom.org api URL, not "obs.osmocom.org".
The latter only works on jenkins because we have set up an alias there,
but not locally without setting up the same alias.
Change-Id: I663ba4f137a57890ba9a2079ef3453bb7544de8b
Increase the logs to keep for gerrit related builds, as they may exceed
the previous limit of 120 within a day. All these jobs don't save build
artifacts, so they should not cause a noticable size increase.
This is a much more careful version of 719ff976 ("jobs: tweak
build-discarder values"), which had been reverted in a052c13c. The
big problem with the previous patch was that it increased the number of
jobs to keep even for jobs that had build artifacts, and so the
required storage exploded.
Related: OS#5980
Change-Id: I1a4604d7a5093349aee0122e74914b06045c78b8
Remove the "artifact-days-to-keep: -1" and "artifact-num-to-keep: -1"
lines, as they don't have an effect. -1 is the default value, which
means "infinite" and causes the value from "days-to-keep" /
"num-to-keep" to get used instead.
This patch re-applies part of 719ff976 ("jobs: tweak build-discarder
values"), which had been reverted in a052c13c.
Related: https://jenkins-job-builder.readthedocs.io/en/latest/properties.html#properties.build-discarder
Related: OS#5980
Change-Id: Ic073643634e1814147d765dd7e8f3f02e81effc3
Oliver Smith
Harald Welte
Neels Hofmeyr