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. You can have the hook run tox or whatever tool your project uses for validation on every commit. This works okay for simple cases, but if the validation takes more than a couple of seconds the delay can be disruptive to the flow of your work.

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.
I also found that many of the tools were opinionated in what sort of output they would produce.