Just for fun

Last week Gerrit Code Review version 2.8 GA was released. It is a major release and devs have spent 8 months and two Hackathons in London and Boulder to release it. The highlights are:

• Secondary index support
• New change screen
• New plugin API

While each of this features can fill out the whole release for itself, all three combined explain why Gerrit users, developers and early adopters are so excited about the availability of Gerrit 2.8 GA.

Secondary index support: Lucene or Solr provider can be activated in 2.8. Still the default is SQL index. In the next version that’s going to change: SQL indexing is removed in Gerrit 2.9 (ETA early February). A number of new query predicates were introduced: “comment:TEXT”, conflicts:’ID’, parentproject:’PROJECT’. For some existing queries nasty restrictions were dropped. Most notably for “file:REGEX” predicate. For the performance reasons it was only possible to search on isWatched predicate for free style regex. Now it is supported form change table: “status:open file:^.*.py” searches for all open changes, where python files were changed.

New change screen: Old change screen is considered to be deprecated and is going to be removed in Gerrit 2.10. The screen was redesigned from ground on. The main difference between old and new change screen is that only one patch set is presented on the new change screen. On old change screen patch set was implemented as an instance of “DisclosurePanel” (GWT) which means, that all patch sets can be expanded at the same time on the screen. Assume that an average change has 10 patch sets, and each one has 17 files, expanded we would see 170 files on the screen and need to scroll a lot. Some invisible changes are support for new UiActions (buttons, that plugin can contributed) and JavaScript API: it is possible to register JS hooks, that are activated when the change screen is entered. More on this later.

New plugin API: there are a lot of enhancements and improvements in the plugin API. To mention a few: plugin can define core capabilities, plugins can define their own name, plugins can extend core UI (change screen and project screen) and place dynamically UiActions (buttons) and html fragments on core Gerrit pages. Even GWT dialogs are supported. New cookbook-plugin was created as a show-case for plugin API.

Here is an example from cookbook-plugin how to extend change screen with own HTML fragment (two columns table). JavaScript hook is registered and get activated when specific events occurs (show change in this case), and custom JavaScript function is called (“onOpenChange” here). Javascript method renders the new html fragment. Usually three steps involved in manipulating the original DOM:

1. request dynamically the data for the resource (specific revision in this case)
2. parse the response
3. render HTML fragment

Gerrit.install(function(self) {
function onOpenChange(c, r) {
var url = "changes/"
+ c._number
+ "/revisions/"
+ r._number
+ "/"
+ self.getPluginName()
+ "~"
+ "greetings";
var change_plugins = document
.getElementById('change_plugins');
Gerrit.get(url, function(r) {
var doc = document;
var frg = doc.createDocumentFragment();
var table = doc.createElement('table');
frg.appendChild(table);
for (var i = 0; i < r.length; i++) {
// row
var tr = doc.createElement('tr');
// greet
var g = r[i];
// first column: message
var td = doc.createElement('td');
td.appendChild(doc.createTextNode(g.message));
tr.appendChild(td);
// second column: country
td = doc.createElement('td');
var a = doc.createElement('a');
a.href = g.href;
a.appendChild(doc.createTextNode(g.country));
td.appendChild(a);
tr.appendChild(td);
table.appendChild(tr);
}
// add frg to #change_plugins container
change_plugins.appendChild(frg);
});
}
Gerrit.on('showchange', onOpenChange);
});

This possibility opens new use cases, like putting CI results for different platforms
and/or job types per patch set with the href to navigate to the result.
This way it is immediately visible in the header of the change screen:

CI bridges (Jenkins Trigger plugin, Zuul and buildbot plugin) must to be adjusted for this to work, but this is of course doubled.
The only reason why such a plugin doesn’t exist yet: it was impossible to extend change screen with dynamic fragments.

In the next blog posts i will show how to migrate to Gerrit 2.8 and how buildbot-plugin makes use of the new and shiny plugin API in Gerrit 2.8, stay tuned.