It’s a bit of an embarrassment when you submit a review to Gerrit only to have it fail CI checks immediately because of something as simple as a syntax error or pep8 failure that you should have caught yourself before submitting…but you forgot to run your validations before submitting the change.
In many cases you can alleviate this through the use of the git pre-commit hook, which will run every time you commit changes locally.
In my last article article I introduced Gruf, a command line tool for interacting with Gerrit. Since then, Gruf has gained a few important new features.
Caching Gruf will now by default cache results for five minutes. This avoids repeatedly querying the server for the same information when you’re just displaying it with different templates (for example, if you run a gruf query open here followed by a gruf -t patches query open here).
(See also the followup to this article.)
I’ve recently started spending more time interacting with Gerrit, the code review tool used both by OpenStack, at review.openstack.org, and by a variety of other open source projects at GerritForge’s GitHub-linked review.gerrithub.io. I went looking for command line tools and was largely disappointed with what I found. Many of the solutions out there assume that you’re regularly interacting with a single Gerrit instance, and that’s seldom the case: more often, the Gerrit server in use varies from project to project.