JGit und EGit werden erwachsen

GitHub Gists

GitHub Gists [11] sind Mini-Git-Repositories, die verwendet werden, um wiederverwendbare Codeschnipsel zu versionieren und zwischen verschiedenen Entwicklern zu sharen. Sie können als Mylyn Task Repository hinzugefügt und als Queries in der Task List View angezeigt werden. Gists können mit einem Task-Editor bearbeitet oder kommentiert werden. Außerdem können sie mit der Menüaktion GITHUB | CREATE PRIVATE GIST oder GITHUB | CREATE PUBLIC GIST angelegt werden, wenn Files selektiert sind oder Text in einem Editor selektiert ist.

GitHub Pull Requests

GitHub Pull Requests können als Mylyn-Task-Repository-Typ hinzugefügt werden. Der Task-Editor für Pull Requests zeigt die Commits im Pull Request an und erlaubt es, diese im EGit Commit Viewer zu öffnen. Das integriert den GitHub-Code-Review-Prozess in die Eclipse Workbench.

Klone und Projektimport von GitHub

Repositories können direkt über IMPORT | GIT | REPOSITORIES from GitHub geklont werden, diese erscheinen nach dem Klonen automatisch in der EGit Repositories View (Abb. 11).

Abb. 11: Repositories View
Gerrit-Integration in den Jenkins-Build-Server: Gerrit-Trigger-Plug-in

Das Jenkins-Plug-in Gerrit-Trigger [12] integriert den Jenkins-Build-Server mit Gerrit, indem es sich über eine stehende SSH-Verbindung auf den Gerrit-Eventstream registriert. Das heißt Gerrit versendet über diesen Mechanismus Events, und das Gerrit-Trigger-Plug-in reagiert dann auf den Event Neues Patchset wurde gepusht mit einem Verifikations-Build. Damit ermöglicht es die automatische Validierung von Changes, die sich noch im Code-Review befinden, bevor sie den Ziel-Branch im serverseitigen Repository erreicht haben. Das erleichtert die Arbeit der Reviewer erheblich, da die Überprüfung des Builds und der vorhandenen automatisierten Tests damit vollautomatisch abgewickelt werden kann. Nach jedem Verifikations-Build gibt das Plug-in eine Wertung im Code-Review ab (normalerweise in der Wertungskategorie Verify), sodass alle Teilnehmer im Review-Prozess über das Ergebnis informiert sind.

Java Git Server: Gerrit-Code-Review

Die Gerrit-Code-Review [13] wurde schon im letzten Artikel vorgestellt. Es vereint die Funktionalität eines Git-Servers mit ausgefeiltem Berechtigungskonzept und dem Code-Review-Workflow, der im Android-Open-Source-Projekt entstanden ist. Das Berechtigungskonzept erlaubt Branch-spezifische Berechtigungen und ermöglicht die Delegation der Projektadministration an die Projekt-Owner. Damit lassen sich auch große Server mit sehr vielen Repositories ohne großen zentralen Administrationsaufwand betreiben. Gerrit skaliert sehr gut und eignet sich auch für große Installationen für hunderte bis tausende Entwickler.

Auch bei Eclipse beginnt gerade der Aufbau eines Gerrit-Servers [14], von dem sich die Foundation eine wesentliche Verbesserung der Infrastruktur für die Community verspricht. Insbesondere der Eclipse-IP-Prozess, der heute auf Bugzilla basiert, wird durch Gerrit wesentlich verbessert, da er dann direkt auf den von Gerrit gehosteten Git Repositories aufgesetzt werden kann und nicht mehr umständlich mit Patches als Attachments von Bugzilla Issues hantiert werden muss. Das IP Log, das für Releases von Eclipse-Projekten zwingend vorgeschrieben ist, soll dann automatisch aus dem Git Log und den Review-Daten in Gerrit berechnet werden.

Gerrit 2.2

Seit einigen Monaten steht die neue Version Gerrit 2.2 zur Verfügung [15]. Es kommt mit einer neuen, flexibleren Oberfläche zur Berechtigungspflege und speichert die Berechtigungen jetzt nicht mehr in einer relationalen Datenbank, sondern im jeweiligen Git Repository in einem verborgenen Git Branch refs/meta/config, der vom Gerrit-Server selbst verwaltet wird und nur von Project Ownern geändert werden kann. Das bringt folgende Vorteile:

  • Berechtigungsänderungen werden versioniert.
  • Project Owner können Berechtigungen fetchen, lokal ändern und committen und dann via Push aktivieren.
  • Bei Umzügen von Git Repositories von einem Gerrit-Server zum anderen werden die Berechtigungseinstellungen automatisch mit umgezogen.

Es ist geplant, in den nächsten Releases sukzessive weitere Gerrit-Daten von der Datenbank nach Git zu verlagern, um damit später unter anderem auch offline Reviews zu ermöglichen.

Ein weiteres neues Feature erlaubt es nun, die Basis für die Diff-Anzeige auf ein beliebiges Patchset zu setzen. Das erleichtert den Code-Review-Prozess für Changes, die mehrere Iterationen des Code-Review-Zyklus durchlaufen. Eine Iteration dieses Zyklus umfasst die folgenden Schritte:

  • neues Patchset für denselben Change veröffentlichen
  • Reviewer geben Kommentare und falls nötig negative Votes
  • dieses Feedback führt meist zu weiteren Anpassungen, die zum nächsten Patchset führen

Mit diesem Feature kann ein Reviewer, der nicht alle Iterationen gesehen hat, zum Beispiel einen direkten Vergleich des neuesten Patchset mit dem letzten, das er reviewed hat, leichter durchführen.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.