Re: RFC: speed up gerrit verifications by using dependency artifacts

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? 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/