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
For some reason, this job still had deb9 nodes listed. Remove them, and
add the deb11 nodes.
Related: OS#5793
Change-Id: I5656edb57165cdab69a5ddace32e7a8c9b3651d9
This reverts commit 719ff97608.
The disk consumption of jenkins has grown by almost 500GB
since we merged this patch. Clearly this is not expected, and we'd
have ran out of disk space in a few weeks.
I personally think the current allocation of 1.5TB of disk space to
jenkins should be more than sufficient; we just need to manage it
better.
Closes: OS#5980
Change-Id: I6b744a8b84a3e1255a8d51f73d1721ccfd028ac1
Add a jenkins job that automatically builds manuals for release tags, if
they don't exist on the server already.
Closes: OS#5902
Related: https://downloads.osmocom.org/docs/
Change-Id: I0ecb238660553c3c857e1b310873eca8a8d09dab
Check if the coverity path already exists. Even this wouldn't
detect if the coverity has been only installed half way.
Related: OS#5801
Change-Id: I95549983bb6bd47e04eb37c73afe5409637f87d3
I've verified that all master-builds jobs still work with this change.
Related: OS#5949
Depends: docker-playground I51925d0ab9e5a779379efab59c381ef12fb60929
Change-Id: I7d5bc7bb4c1457d4e05fd6e0d27668382c39973a
Prepare to let all master-builds jobs use debian-bullseye instead of
debian-buster.
Depends: docker-playground I8e1741f86ffb8abd658d1e4e0415dfd11fb1a8a1
Related: OS#5949
Change-Id: I55bd5869ecd753549b8f2f2822e825623d940acd
Build the manuals with the regular docker image, instead of the
fpga-build one.
Fix for:
build/shrink-pdfs.sh: 8: build/shrink-pdfs.sh: ps2pdf: not found
Related: SYS#6380
Change-Id: I6e9f832dc449af0ca7def29ef5a9161285b01736
Add a nightly jenkins job that does the following:
* Clone Wireshark from upstream
* Merge several Osmocom branches on top
* Build a source package
* Submit it to the osmocom:wireshark OBS project
Related: OS#2537
Change-Id: Ifb49c5cb22a4de0da30a920e5450a27172b11d73
Prepare to add a wireshark package. It will be in its own
osmocom:wireshark repository, and not in osmocom:nightly, :latest,
:master, so it's not added to lib/config.py.
Move lib.set_args() before parse_packages(), so the latter is able to
use lib.args.allow_unknown_package.
Related: OS#2537
Change-Id: I007f937ccb629e0593ec9253541ed05df42fac66
During refactoring, conflict_version was changed to version here, which
was wrong. The packages need to depend on the conflict_version of the
meta package, version is the version of the package itself.
Fix for:
The following packages have unmet dependencies:
libosmo-netif-dev : Depends: osmocom-nightly (= 202303160009) but it is not going to be installed
Depends: libosmocore but it is not going to be installed
Depends: libosmonetif11 (= 1.3.0.8.9e65.202303160009) but it is not going to be installed
libosmocore-dev : Depends: osmocom-nightly (= 1.8.0.79-b394d.202303170006) but it is not going to be installed
Depends: libosmocore but it is not going to be installed
Fixes: 0ed0e464 ("obs: don't pass conflict_version through functions")
Change-Id: I2326e3817c6f6887ef1196e603c3877768119a66
Prepare to use this for wireshark, to build a branch on-the-fly that
does not get pushed to origin, with Osmocom patches on top of upstream
master.
Related: OS#2537
Change-Id: Ifc963daf51ba3542f67420daaf7b29745404a92e
Oliver Smith
Harald Welte
Neels Hofmeyr
Alexander Couzens