As you may know, LibreOffice undergoes currently migration to code review system gerrit. In his post to dev ML Why Gerrit and other consideration Norbert Thiebaud explained the objectives which the initiators of that move are trying to achieve. As though by chance, the first reason behind that move was cit.
a/ Allow dev to pre-build commit on a variety of platform before
pushing them to master. iow check and push rather than the current
push and fix.
To see how gerrit fits in current LibreOffice CI picture or what should be done for it let us first take a look at the situation prior to gerrit migration. At the moment there are 23 Tinderboxes (TB), that independently running on donated machines and asynchronously verify different git branches. They upload the build results to the master TB per mail. Master TB extracts the log from the mail and puts it to the web site for that specific branch, i.e. for master you can find it here.
So basically we have to set up some process let us name it task queue that has to solve the follow challenges to integrate TB and gerrit change verification:
one gerrit change must ber verifies on variety of platform simultaneously by different TB.
ACL: only authorized gerrit user might (mostly member of non nteractive group, i. e. BuildBot) be able to do it.
if more then one TB exists for each platform engaged in gerrit patch verification (and this is often the case) only one TB may win the gerrit change verification competition. Obviously that require something that behaves like a blocking queue for each platform.
One combined approval message for all platform has to be reported back to gerrit: +a if and only if all tasks on all platform were successful. -1 otherwise.
idle-timeout: if task is scheduled to platform specific verification queue and was not picked up. Note: it is not a failure.
engaged-timeout: task was picked up, but no result was reported during reasonable amount of time. In that case one can think about recovering process: reschedule the same task once time again to platform specific verification queue.
Receive the log files from TB and present them. It is clear that fire and forget functionality (TB send per mail result to master TB) doesn’t work with gerrit, because the verification message must contain link to the log file and TB master is not involved in that use case.
Communication between tinbuild2 (bash script) and gerrit itself.
LibreOffice is not the first project that integrates gerrit with CI Infrastructure. We have Jenkins Gerrit Trigger Plugin and Openstack project has zuul. But what makes the situation unique is the fact, that the TB don’t maintain the continuous connection to any master, they appear only for a moment, pick a task, disappear, report results and so on. To address this problem a new approach must be implemented.
Since version 2.4 and upcoming 2.5 gerrit provides mature plugin architecture. gerrit plugin has access to all gerrit services, including
native support for SSH commands.
stream event listener provides access to all gerrit events, i.e. patchset created.
publish event factory used to report review/verify message for gerrit change
HTTP module integrates with gerrit web application. It is needed to implement access to the log files, received from TB.
(edit: removed spam)