As always after the Gerrit User Summit, a Gerrit hackathon took place.
This time it was a five days event (9-11 November 2015), where members of the Gerrit community could work together, fully focused on making Gerrit a better software.
2015 edition gathered 15 participants from various companies like Google, SAP, Sony Mobile, Qualcomm, OpenStack, Axis Communications, Gerritforge and of course CollabNet.
Hackathons are really intensive periods of time for Gerrit project: over 400 patches were merged, three releases (2.11.5 and two release candidates of 2.12) were performed, countless number of open changes and patchsets were pushed for review.
This blog post summarizes work done during that period of time, showcasing new features upcomming in 2.13 and 3.0 release.

Gerrit metrics

If you are responsible for running mission critical software for your organization, you must know how important monitoring and metrics are. How important it is to get fine grained information about the application performance. It is simply not enough to know whether it is up and running but also what is the overall shape of it.
This kind of information is especially critical when users start complaining “Gerrit is slow”.
From time to time such complaints arrive also to our team in Potsdam, then we use Splunk to analyze the load based on Gerrit logs and give our recommendations how to tweak Gerrit. Based on such cases our Gerrit Performance Cheatsheet was composed meuh7iu.
Starting from Gerrit 2.13 we will have a new tool in our toolbox! Internal Gerrit metrics!
DropWizard Metrics library is used as internal engine. Gerrit exposes over 1300 metrics about crucial internals e.g. http server response time, git receive pack, git counting objects, cache sizes, etc….
What is even more awesome, plugins can report their own metrics using the core API. This way replication plugin for 2.13 will report time taken to replicate repository data to various locations.
One thing is to collect metrics, the other is to store them. For this purpose three new plugins were created: metrics-reporter-elasticsearch, metrics-reporter-graphite and metrics-reporter-jmx. This gives possibility to plug Gerrit in into already existing infrastructure.

Hooks as plugins for core events

There are two ways in Gerrit how one can be notified about git operation related events. One is via event mechanism and another via Gerrit hooks. Both provide almost identical functionality making deciding on implementing one of them harder.

During our hackathon work was started to extract hooks mechanism into plugins that would listen to core Gerrit events.

This work is still ongoing, but once it gets finished one that want to run server side hooks must install the Gerrit hook plugin.

gwtorm can be used from plugins

You may be wondering what is the gwtorm. This is a library written for Gerrit project to access relational databases. It is a lightweight method of connecting your Java application to multiple different DB backends. Initially it was meant to be used only by GWT based applications (hence gwt prefix in its name), but currently it can be used by any Java application.

Why to use gwtorm in plugin? Well if you don’t want to modify Gerrit schema (which is highly discouraged) to store your plugin data and want to support many SQL dialects out of the box, gwtorm is the way to go.

The first plugin that will use this library is gerrit-ci-plugin.

Gerrit 2.11.5 and 2.12-rc

Gerrit releases don’t happen too often. Some time we had to wait long months (and over 1000 commits) to get new stable version of Gerrit. Usually just before the hackathon a release candidate of new stable version is cut from the master branch.

During this year’s hackathon we got three releases! One was a service release for 2.11 (updated release notes) branch containing fixes for javascript clipboard, styling, commit validation error handling.

Apart from service release two release candidates were published for Gerrit 2.12.

Submit whole topic dialog

Gerrit 2.12 changes how patches are submitted to the repository after code review. In all previous versions there was so called “merge queue” which was responsible for submitting patches in the right order. If particular change was submitted but its ancestors were still under review it ended up in a special state “submitted, merge pending”.

In 2.12 changes arranged in a branch (one change depending on the other) can be submitted at once by single click on the submit button on the topmost change.

Additionally new feature called ‘submit whole topic’ was added. It enables submission of changes that share the same topic. This can be done across multiple projects and branches.

One thing that struck us when this feature was presented during Gerrit User Summit was change in the semantic of Gerrit ‘topic’. Before 2.12 topics were only metadata that could have been freely added and removed. Plus there was possibility to search for changes that share the same topic. Starting from  2.12 setting a topic on changes will change how they are submitted. In some rare cases one can submit changes of others or block them because of a change not visible to all is still waiting for being reviewed.

To make submitting more verbose during the transition period, a submit dialog was proposed. It pops up after clicking on the submit button only when changes from the same topic would be submitted. It presents the list of changes submitted in a topic and without it, so that the submitter can choose whether to just merge the change in question or all changes of the same topic.

CI verification

Some time ago a Diffy build bot was introduced to verify changes pushed to gerrit-review.googlesource.com, but after some time it become unreliable, often was simply not verifying because it was not running.
Now there is new verifier in the picture. Based on proven gerrit-trigger-plugin custom REST API pooling strategy and Jenkins tandem. It is kindly hosted by the GerritForge. Long life to new GerritForge CI bot!

NoteDB

NoteDB is the defining feature of Gerrit 3.0. It will replace “conventional” database system and store everything inside git repositories. All the data that is currently stored in SQL DB will be moved to git repositories. Review related information will be stored in the particular repository using git-notes and special refs. User data will be moved to dedicated repository.
During the hackathon further steps into achieving the goal of removing the dependency from SQL DB were performed, some integration tests were fixed plus NoteDB tests were enabled  as a part of verification job.

New Gerrit UI with Polymer

Last but not least, the new Polymer based WEB UI for Gerrit was initially announced and integrated into Gerrit’s build process.

During the Gerrit User Summit, Google has presented the draft of a new Gerrit WEB UI. This time it is written using Polymer framework, which is a new JavaScript UI design framework from Google.

The new WEB UI will be fully written in JavaScript, making it easier for UI/UX designers to modify and faster to develop and compile.

As I mentioned before, during hackathon PolyGerrit project was integrated into standard Gerrit build system. It requires teaching Buck how to deal with javascript and its dependencies.

What is next?

Next is the Berlin Gerrit Hackathon in 2016. We’ve open a poll to gather input from the community about preferable date between 22nd of February and 25th of March 2016. Please participate if you would like to join us and hack Gerrit in Berlin 🙂