Gerrit Code Review
The web interface of our Gerrit installation can be accessed at http://hydra.wycliffe.ca:9160
Create a user on Gerrit by signing in with OpenId (such as a Google account). Please send Eberhard an email afterwards so that you can be given the correct permissions. If you are outside of the Calgary/Dallas/Waxhaw LAN you’ll need ssh access - please contact us.
To review code on Gerrit, log in to Gerrit. You can see a list of all open change sets that are waiting to be reviewed. If you click on one it displays this change set in detail. By clicking on a file name you can see the differences.
It is possible to ignore whitespace when showing the differences by choosing “Ignore Whitespace: All” and unchecking “Intraline Difference”. Note that there is a bug that doesn’t allow to ignore whitespace while showing intraline differences.
It is possible to compare different versions of a change set. Consider the following scenario: the developer submitted code for review, you did the code review but discovered some things that need to be changed. The developer fixes the code and uploads the changes again. When you look at the new changes now you can compare them to the code in the remote repo or to the previous changes. To do that expand the “Patch History” button at the top of the page and select what you want to compare.
You can add comments on a line by double clicking the line. The Save button below the comment editing box allows you to save the comment as a draft (visible only to you). To make the comments publicly visible, press the Review button on the details page.
To finish a code review press the Review button, check the appropriate radio buttons and optionally add a comment for the entire change set. Then press the “Publish” or “Publish and Submit” (might not be visible, depending on permissions) button. By pressing the “Publish and Submit” button the changeset gets merged into the remote repo, pressing “Publish” marks the changeset as reviewed but someone else needs to submit it to the remote repo later. You’ll get an error message if the submit fails, e.g. because the patches can’t be merged into the remote repo because of conflicting changes. In this case the developer needs to do the merge locally and re-submit the changes for code review.
Submit is only possible if the change set has a +2 for code review and a +1 in the Verified column.
When you do a code review you would give a +2 if you’re satisfied with the changes and you want them to be submitted as is (Note that giving a +2 doesn’t automatically submit, it only marks it as being ready for submit). You would give a +1 if the changes look good to you but you’re not so familiar with that area of the code and would like someone else to have a look at these changes.
You’d give a -1 if you found some small problems that you’d like to have changed but it would be OK if someone else decides that they’re good as is. A -2 says that this patch set has major problems and can/should not be checked in without some modifications.
By setting the Verified column you testify that the patch set builds correctly.
Note that it is possible to add a comment to the change set without giving any points in the code review column.
Submitting Code for Code Review
Gerrit relies on a Change-Id line in a commit message so that updates to a patch are recognized. This can be created with a git hook. To install the hook, copy it from Gerrit's daemon:
$ scp -p -P 29418 firstname.lastname@example.org:hooks/commit-msg .git/hooks/
You have to do this for each project you're working on.
You need to tell Gerrit about your public SSH key if you want to be able to upload changes to Gerrit. Instructions are available here.
Uploading changes for review
To upload changes for review:
$ git push ssh://email@example.com:29418/projectname HEAD:refs/for/master
You can edit your ~/.ssh/config file and add:
Host gerrit Hostname hydra.wycliffe.ca Port 29418 User mygerritusername
Then you can upload changes with:
$ git push gerrit:projectname HEAD:refs/for/master
Draft Changes and Patchsets
Starting with Gerrit 2.3 it is now possible to upload draft changes and patchsets. Those changes and patchsets will appear with (Draft) appended and are visible only to you and any explicitly added reviewer. The use case for this is that you want to upload your change but not make it publicly accessible, e.g. because you don't want people to start reviewing it yet.
To upload draft changes or patchsets push to refs/drafts instead of refs/for:
$ git push ssh://firstname.lastname@example.org:29418/projectname HEAD:refs/drafts/master
Draft changes and patchsets have a new Publish button that can be used to make the change/patchset publicly visible. Alternatively this can be done from the command line: to publish the change with commit c0ff33:
$ ssh -p 29418 email@example.com gerrit review --publish c0ff33
(Needs to be verified) It is possible to trigger a Jenkins build on a draft change by explicitly adding Jenkins as reviewer.
Gerrit and Builds on Jenkins
As soon as changes get uploaded to Gerrit for review a build of those changes will be started and the result reported in the Verified column in Gerrit.
Retriggering Gerrit builds on Jenkins
If a build fails for the wrong reasons, a new build can be retriggered on the Jenkins web site. Go to the details of the failed build, then click the "Retrigger" link on the left.
The Gerrit-builds attempt to be smart and only do a complete remakefw if something significant has changed. However, sometimes the guess is wrong. In these cases it is possible to force a remakefw by copying the link target from the "Retrigger" link and appending "?ForceRemake=1", e.g. http://hydra.wycliffe.ca:9000/view/Gerrit/job/Gerrit-FW-Linux32-CalgaryWW-debug--Calgary/42/gerrit-trigger-retrigger-this?ForceRemake=1.
Using the Gerrit Sandbox
It is possible to upload changes to a personal sandbox on Gerrit. This way a change can be shared between machines and developers before it is ready for code review.
To upload a change to the personal sandbox:
$ git push ssh://firstname.lastname@example.org:29418/projectname HEAD:refs/sandbox/mygerritusername/branchname
To list available sandboxes for user mygerritusername:
$ git ls-remote ssh://email@example.com:29418/projectname 'refs/sandbox/mygerritusername/*'
To delete a branch in the personal sandbox:
$ git push ssh://firstname.lastname@example.org:29418/projectname :refs/sandbox/mygerritusername/branchname