RFC: speed up gerrit verifications by using dependency artifacts

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

André Boddenberg dr.blobb at gmail.com
Fri Mar 31 14:23:23 UTC 2017


>> Would anyway make sense to build dependencies once per build slave in a project
>> where each build slave is a different OS or config instead of sharing load.

Actually the current approach works like that. Each build slave simply
has its own directory for holding compiled-dependencies-artifacts. The
osmocom docker image might need an additional volume to mount the
artifact store, in case /build_bin/artifactStore - which is already
mounted - isn't suitable.

One thing probably worth discussing is which job(s) should
expose/archive artifacts. In the current approach every job that
cannot find the latest dependencies will try to archive/expose them
after building from scratch.

Of course we could dedicate this role to a specific job e.g. [1], but
I simply didn't (want to) think about such approach. So currently all
jobs that profit from dependency artifacts, will archive compiled
dependencies in case no artifact holding the latest dependencies was
found (and no other project, which compiled the same dependencies
finished before).

Practically, the mentioned job [1] will almost always update
artifacts, because the chances that a gerrit job finishes before [1]
correlates proportionally with the polling intervals of all upstream
projects of [1].

In theory a patchset could profit by the artifact archived by its
previous patchset, when the duration of both verifications is shorter
than the above mentioned polling intervals and no change to any
dependency has been introduced meanwhile.

What do you think makes most sense one/several/all job(s) to update artifacts?


>> The good news is that the dep branches have become unnecessary just two days
>> ago. I will remove them from the build scripts now.

Nice, I will apply these changes for openbsc jobs on my jenkins as well.

blobb

[1] http://jenkins.osmocom.org/jenkins/view/OpenBSC/job/OpenBSC/



More information about the OpenBSC mailing list