Just for fun

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.

To see how it fits all together, look at that picture:

1. Buildbot gerrit plugin listens to gerrit patch set created events.
2. developer uploads a patch set to gerrit.
3. Listener receives the event and creates a GerritJob instance with n TB tasks (one per each platform). Those tasks are maintained in platform specific blocking queue.
4. TB ask per ssh for a task with get-task command (for their platform). The task is removed from the queue and TB is engaged. In that way it is guaranteed that only one TB get the same task to build.
5. Once ready TB reports the result and send the log file and the status per ssh with report command.
6. When the last task status is reported for the gerrit job is considered as ready and combined verify message is reported back to gerrit. The message contains the links to the log files for all checked platform.
7. Behind that link the the own log file servlet is located.

Current status of plugin: basic functionality is provided. Code must be consolidated and more tests and feature must be implemented: Multi project support, Admin GUI, persistence of queue, timeout behaviour. If you want contribute you can find the code … on gerrit: Buildbot-gerrit-plugin. Here are steps how to contribute:

1. register with OpenID to gerrit and upload your public keygerrit:.
2. clone the repo:
   git clone ssh://davido@review.idaia.de:29418/gerrit-buildbot.git .
3. install git-review:
   sudo pip install git-review
   and set it up: git review –setup
4. change something and commit
5. push to gerrit:
   git review
6. wait for verification/approval.