Like the gerrit-verification jobs for libosmocore, run the master-builds
jobs on nodes with the io_uring label.
Related: OS#6405
Change-Id: Iea6791b3fbb5c445a539c2b4636a643d6c8d517b
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
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
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
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
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
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
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
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
I've verified that all master-builds jobs still work with this change.
Related: OS#5949
Depends: docker-playground I51925d0ab9e5a779379efab59c381ef12fb60929
Change-Id: I7d5bc7bb4c1457d4e05fd6e0d27668382c39973a
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
Remove num-to-keep from most jobs, as this leads to keeping the build
logs for a much shorter timeline than desired. For example the
gerrit-binpkgs-deb job that runs for most projects when pushing patches
to jenkins reaches the 120 limit in less than 24h - and so when clicking
the link on a failed build from yesterday it is already deleted.
Instead just keep the logs for the last 30 days, no matter how many were
submitted on one day. Storing logs doesn't take up much space.
Remove the artifact-days-to-keep and artifact-num-to-keep lines, as they
don't have an effect. For jobs that do have artifacts, the actual value
is min(days-to-keep,artifact-days-to-keep) and same with num-to-keep.
While at it, increase the ttcn3-testsuites build-discarder to 120 days
as this means more data will show up in the test result analyzer at
which we look frequently.
Change-Id: Iec5c22c7fcf6c1fd2db71611045f15dc6580ed86
Don't attempt to create the CCACHE_DIR and chown it to osmocom-build for
the simtester jenkins node, and more generally all that were not
created with the ansible provisioning scripts. In case of simtester,
there is no osmocom-build user and we don't have the space there to use
ccache.
Fix for:
chown: invalid user: ‘osmocom-build:osmocom-build’
Related: OS#5848
Change-Id: I339d9ba4ad0c959d7325820eb53bfa1f0e04c164
Put arguments for ccache into a new docker_run_ccache variable, and use
it with all projects where it makes sense to use ccache.
Other projects use docker_run without the ccache parameters again:
* osmo_ss7, osmo_dia2gsup, pysim:
Erlang/Python projects
* osmo-e1-hardware, ice40-usbtrace, no2bootloader, osmo-opencm3-projects:
Don't use the default docker image
* osmo-gsm-tester:
Only builds manuals (jenkins-build-manuals.sh)
Jenkins job builder's variable substitution doesn't replace {docker_run}
inside docker_run_ccache when used in cmd, so just duplicate the lines.
Related: OS#5848
Change-Id: Ib6d7f309b972979d3a3bc87f8fcf71f9e930c0da
Building debian-buster-jenkins on the raspberry pis may take > 1h,
depending on what changed. It has a lot of things we don't use, so build
and use a minimal image with the rpis instead.
Closes: OS#5863
Depends: docker-playground I4fb4b48b233acaef815c4c27ec6f17f12cfe836b
Change-Id: I73e62fbbf93824c0d37963039de4e00f26a43cbe
This script was supposed to cache already built Osmocom libraries. But
it was only used with openbsc, didn't work as expected anymore (looking
at openbsc-master, it just builds all deps from source without caching)
and will be replaced with logic that allows using ccache in a future
patch.
Using ccache has the big advantage that we can cache all build objects
where the source files did not change, and not just do it on a
dependency level. Oftentimes only few source files change in our
patches, so we can really cache everything else that is not affected
within any git repository and not just a dependency that didn't change.
ccache also does automatic cache size management to ensure a cache stays
within a given size limit.
Related: OS#5848
Depends: openbsc Ib3272feec76b30412ca60dec204255b64e33831b
Change-Id: Id94d6126b476077d57839e4a884621b8c034f0c6
As discussed with Pau, let's build the "osmo-iuh/master" branch of our
asn1c.git repository in jenkins. This branch is what we actually use for
osmo-iuh and "master" should track upstream master.
Related: OS#2435
Change-Id: Ic97a23a175b301e6f42f7ca67deb84dcc3ee3f90
Do not set a node for master-builds and gerrit-verifications to run on,
as this leads to needlessly blocking slots on the jenkins nodes.
Each of these jobs is a matrix job with a slave_axis. The matrix job
itself can run on the "builtin" node, as it practically doesn't cause
load - all it does is start other jobs in the matrix (even if there is
only one other job, which is the default). Jobs started in the matrix
job do run on a configured node already, as the slave_axis parameter is
set.
I've just noticed this problem because currently the raspberry pi nodes
are offline, and so the master-osmo-trx, master-osmo-pcu and other jobs
take up lots of build slots just to wait until the raspberry pi nodes
come online and an actual build can start.
Change-Id: I447dd152fcc942ec48d0bcfbadd496e879c882da
Make the binaries_ftp.osmocom.org ssh credentials available to more jobs
that need them.
Related: OS#5798
Change-Id: I4f719c6daba06dcfadd252a4030293bdc0e26337
Allow overriding the ssh agent credentials per repository, and use
binaries_ftp.osmocom.org where needed. Use docs_ftp.osmocom.org instead
of 97634b9d-a867-4f6d-825d-1da99813e93d so it's clear what the key is
for. I generated a new one with the new ID.
Fixes: OS#5798
Change-Id: I821968e09aaac3f6f6178de33fc909f81cb4abcb
Don't require the debian 9 lxc anymore for publishing docs, the ssh key
problem that made this necessary has been solved.
Closes: OS#5767
Change-Id: Ia4ee524db059a978bedc1d92804fb59d7513d2cb
Pass the ssh agent to docker for master builds, so we can publish
manuals and other files generated during the builds. This used to work
with the .ssh directory where each lxc had its own key. But we are
changing that to have the keys in jenkins and use the ssh agent, so it
works without additional configuration when adding new nodes/lxcs (such
as the two deb11 lxcs we just added).
Change-Id: I6dc1fd5d7e81ec135f805562608f06cf03a1baeb
Split the test, pylint and docs job types in the matrix to run them in
parallel.
Depends: pysim I5245c529db729e209d78a02ab9c917a90d0e0206
Related: OS#5497
Change-Id: Iea4f15fd9c9f8f36cb8d638c48da000eafe746a4
Split the job, so building the software can be done with the regular
docker image instead of the fpga-build one (that doesn't have the needed
dependencies).
Related: osmo-e1-hardware I26e839de419c6eb86bf2a6250a1adf06b761d1fa
Change-Id: I90fbe72c722e491f41b9607d1a6389964d7e43b4
Add one new job for building source packages and sending them to
obs.osmocom.org. Trigger it from all master-* jobs.
I've also considered adding one job per existing master job that would
only update one package at a time (master-libosmocore-obs,
master-osmo-bsc-obs, ...). With some additional development effort it
should be possible, and it would make each individual master OBS job
faster. But given that with the current implementation it only takes
20s to 30s for *all* packages if there are no changes, as it compares
git remote HEAD with the version currently on OBS before starting to
clone repositories and building the source packages (similar to
Osmocom_OBS_latest_obs.osmocom.org), it didn't seem worth optimizing.
Set concurrent to false as the triggers from master-builds will likely
cause it to run multiple times in parallel otherwise.
Related: https://jenkins.osmocom.org/jenkins/view/OBS/job/Osmocom_OBS_master_obs.osmocom.org/
Related: https://obs.osmocom.org/project/show/osmocom:master
Related: OS#2385
Change-Id: I53a494f13f81ae837f2d362c54e1bdf13f121db3
I didn't receive mail notifications about failing
master-osmo-opencm3-projects jobs. It seems they are not getting
through on the gerrit-log mailing list, searching for jenkins gives no
results:
https://lists.osmocom.org/hyperkitty/search?mlist=gerrit-log%40lists.osmocom.org&q=jenkins
And it seems to be the wrong ML anyway, so change it to
jenkins-notifications.
Change-Id: I15a747411d928055c71603cd4475289a77c8e749
In case one of the master-buils is segfaulting or has an error in the
testsuite, collect the relevant files and store them as artifacts.
It was asked in the related issue to do this only on error, however
while there's an option to archive only artifacts when a build is
successful, there is not an option to do it only on failure. So just do
it always, the testsuite.log file is typically just a few kb in size.
core files should only get generated on error.
Closes: OS#5642
Change-Id: I91d4b995b16c8e028a5dff19b0e0f09c01d8c8c6
git.osmocom.org is a mirror of gitea.osmocom.org, let's build from
the actual master repo, not from the (possibly slightly outdated) mirror
Change-Id: I12d090a9ee7fde09892567ada739826484a4a35b
* master-libosmo-pfcp is triggered directly by libosmocore, not
by master-libosmo-netif, nor master-libosmo-abis, so
** fix comment explaining the hierarchy.
* master-osmo-upf is triggered by master-libosmo-pfcp, so
** it should not be triggered directly by libosmocore.
Change-Id: Ie4a5cb47464e9abfc9d04e63e9e71619f33ffd42
Fixes: Icb75adec886cf1053b80c968fea59e597ed289a7
Oliver Smith
Harald Welte
Vadim Yanitskiy
Neels Hofmeyr