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
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: Ibc0527a6f7d11c4f99c19e73c948b9baacd4e5a2
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
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
Oliver Smith
Harald Welte