Announce: gerrymander 1.5 “some beans and some beans is four!” – a client API and command line tool for gerrit

Posted: February 22nd, 2016 | Filed under: Coding Tips, Fedora, OpenStack, Virt Tools | Tags: , , , , | No Comments »

I’m pleased to announce the availability of a new release of gerrymander, version 1.5. Gerrymander provides a python command line tool and APIs for querying information from the gerrit review system, as used in OpenStack and many other projects. You can get it from pypi

# pip install gerrymander

Or straight from GitHub

# git clone git://github.com/berrange/gerrymander.git

If you’re the impatient type, then go to the README file which provides a quick start guide to using the tool.

This release contains a mixture of bug fixes and new features

  • Honour the ‘files’ parameter in the ‘todo-noones’ command
  • Only match filenames against current patchset
  • Handle pagination with gerrit >= 2.9
  • Avoid looping forever if sort key is missing in results
  • Don’t call encode() on integer types
  • Auto-detect gerrit server from git remote
  • Don’t include your own changes in todo lists
  • Fix type casting of cache lifetime values in config file
  • Optionally show hierarchical relationship between changes via new ‘–deps’ option

Thanks to everyone who contributed this release, whether by reporting bugs, requesting features or submitting patches.

Announce: gerrymander 1.4 “On no account mention the word Macbeth” – a client API and command line tool for gerrit

Posted: September 3rd, 2014 | Filed under: Coding Tips, Fedora, OpenStack, Virt Tools | Tags: , , , , | No Comments »

I’m pleased to announce the availability of a new release of gerrymander, version 1.4. Gerrymander provides a python command line tool and APIs for querying information from the gerrit review system, as used in OpenStack and many other projects. You can get it from pypi

# pip install gerrymander

Or straight from GitHub

# git clone git://github.com/berrange/gerrymander.git

If you’re the impatient type, then go to the README file which provides a quick start guide to using the tool.

This release contains a mixture of bug fixes and new features

  • Add command for reporting potentially approvable patches
  • Add command for reporting potentially expirable patches
  • Allow todo list commands to be filtered on filename
  • Remove hardcoded #!/usr/bin/python3 lines
  • Fix traceback on casting unicode strings
  • Allow filtering reports based on topic
  • Fix typo in keyfile setting in example config

Thanks to everyone who contributed patches that went into this new release

 

Announce: gerrymander 1.3 “Any history of sanity in the family?” – a client API and command line tool for gerrit

Posted: July 30th, 2014 | Filed under: Coding Tips, Fedora, OpenStack, Virt Tools | Tags: , , , , | No Comments »

I’m pleased to announce the availability of a new release of gerrymander, version 1.3. Gerrymander provides a python command line tool and APIs for querying information from the gerrit review system, as used in OpenStack and many other projects. You can get it from pypi

# pip install gerrymander

Or straight from GitHub

# git clone git://github.com/berrange/gerrymander.git

If you’re the impatient type, then go to the README file which provides a quick start guide to using the tool.

This release contains a mixture of bug fixes and two new features. When displaying a list of changes, one of the fields that can be shown per-change is the approvals. This is rendered as a list of all the -2/-1/+1/+2 votes made against the current patch set. The text is also coloured to make it easier to tell at a glance what the overall state of the change is. There are two problems with this, first when there were a lot of votes on a change the list gets rather too wide. The bigger problem though has been the high level of false failures in the OpenStack CI testing system. This results in many patches receiving -1’s from testing, which caused gerrymander to colour them in red:

+-------------------------------------+-------------------------------------------------------+----------+-----------------------+
| URL                                 | Subject                                               | Created  | Approvals             |
+-------------------------------------+-------------------------------------------------------+----------+-----------------------+
| https://review.openstack.org/68942  | Power off commands should give guests a chance to ... | 186 days | w= v=1,1,1,1 c=-2,-1  |
| https://review.openstack.org/77027  | Support image property for config drive               | 152 days | w= v=1,-1,-1,-1 c=-1  |
| https://review.openstack.org/82409  | Fixes a Hyper-V list_instances localization issue     | 128 days | w= v=1,-1 c=-1        |
| https://review.openstack.org/88067  | Allow deleting instances while uuid lock is held      | 104 days | w= v=1,1,1,1 c=2      |
| https://review.openstack.org/108013 | Fixes Hyper-V agent force_hyperv_utils_v1 flag iss... | 12 days  | w= v=1,1,1,-1 c=1,1,1 |

My workflow is to focus on things which do not have negative feedback and so I found this was discouraging me from reviewing stuff that was only marked negative due to bogus CI failures. So in this new release, the display is now using separate columns to report test votes, code review votes and workflow votes, each column being separately coloured. Also, instead of showing each individual vote, we only show the so called “casting vote” – ie the one that’s most important, (order is -2, +2, -1, +1)

+-------------------------------------+-------------------------------------------------------+----------+-------+---------+----------+
| URL                                 | Subject                                               | Created  | Tests | Reviews | Workflow |
+-------------------------------------+-------------------------------------------------------+----------+-------+---------+----------+
| https://review.openstack.org/68942  | Power off commands should give guests a chance to ... | 186 days | 1     | -2      |          |
| https://review.openstack.org/77027  | Support image property for config drive               | 152 days | -1    | -1      |          |
| https://review.openstack.org/82409  | Fixes a Hyper-V list_instances localization issue     | 128 days | -1    | -1      |          |
| https://review.openstack.org/88067  | Allow deleting instances while uuid lock is held      | 104 days | 1     | 2       |          |
| https://review.openstack.org/108013 | Fixes Hyper-V agent force_hyperv_utils_v1 flag iss... | 12 days  | -1    | 1       |          |

The second new feature is the ‘patchreviewrates’ command which is reports on the review comment activity of people over time. We already have ‘patchreviewstats’ command which gives information about review activity over a fixed window, but this doesn’t let us see long term trends. With the new command we’re reporting on the daily number of review comments per person, averaging over a week, and reported for the last 52 weeks. This lets us see how review activity from contributors goes up and down over the course of a year (or 2 dev cycles). I used this to produced a report which I then imported to LibreOffice to create a graph showing the nova-core team activity over the past two cycles (click image to enlarge)

Nova core team review rates

Nova core team review rates

In summary the changes in version 1.2 of gerrymander are

  • Exclude own changes in the todo lists
  • Add CSV as an output format for some reports
  • Add patchreviewrate report for seeing historica approvals per day
  • Replace ‘Approvals’ column with ‘Test’, ‘Review’ and ‘Workflow’ columns in change reports
  • Allow todo lists to be filtered per branch
  • Reorder sorting of votes to prioritize +2/-2s over +1/-1s
  • Avoid exception from unexpected approval vote types
  • Avoid creating empty cache file when Ctrl-C’ing ssh client
  • Run ssh in batch mode to avoid hang when host key is unknown

Thanks to everyone who contributed patches that went into this new release

Announce: gerrymander 1.2 “As effective as a cat-flap in an elephant house” – a client API and command line tool for gerrit

Posted: July 3rd, 2014 | Filed under: Coding Tips, Fedora, OpenStack, Virt Tools | Tags: , , , , | No Comments »

I’m pleased to announce the availability of a new release of gerrymander, version 1.2. Gerrymander provides a python command line tool and APIs for querying information from the gerrit review system, as used in OpenStack and many other projects. You can get it from pypi

# pip install gerrymander

Or straight from GitHub

# git clone git://github.com/berrange/gerrymander.git

If you’re the impatient type, then go to the README file which provides a quick start guide to using the tool.

The changes in version 1.2 are

  • Don’t drop ‘Restored’ comments in ‘comments’ command
  • Change ‘assertEquals’ to ‘assertEqual’
  • Print list of options for ‘changes’ command in help message
  • Send all output via a pager (eg less or whatever $PAGER says) Can disable via setting GERRYMANDER_PAGER=cat env var.
  • Fix ordering of comments when > 10 patch sets are present
  • Handle remaining event types
  • Stop subprocesses getting signals intended for main process
  • Improve colourization of review votes

Thanks to everyone who contributed patches that went into this new release

Gerrymander tips & tricks – defining default command options and adding custom commands

Posted: May 23rd, 2014 | Filed under: Coding Tips, Fedora, OpenStack, Virt Tools | Tags: , , , , | No Comments »

I recently announced gerrymander, a python client tool and API for extracting information from Gerrit, intended to replace my use of various other ad-hoc tools that people have developed. One of the things I observed with using the previous qgerrit command line tool was that there were a couple of different sets of command line arguments that I used all the time. This was tedious so I ended up creating a number of shell wrapper scripts / aliases to invoke qgerrit with different sets of arguments. With gerrymander though, I wanted to do things a little better by defining this stuff as data rather than code. ie using configuration files, instead of wrapper scripts/aliases.

Taking the ‘changes’ command as an example, it is a generic command for displaying lists of changes in gerrit for a given query. The default behaviour is to output 7 columns: status, url, owner, subject, creation date, last updated date and approvals.

$ gerrymander changes -p openstack/nova-specs 
Changes
-------

+-----------+------------------------------------+-----------------------------+-----------------------------------+----------+----------+-------------------------------+
| Status    | URL                                | Owner                       | Subject                           | Created  | Updated  | Approvals                     |
+-----------+------------------------------------+-----------------------------+-----------------------------------+----------+----------+-------------------------------+
| MERGED    | https://review.openstack.org/80785 | russellb                    | Add README and base directory ... | 68 days  | 66 days  | w=1 v=2 s=1 c=2,2             |
| NEW       | https://review.openstack.org/80865 | mikalstill                  | Proposed blueprint for libvirt... | 67 days  | 1 days   | v=-1 c=1,1,-1,-1,-1,-1        |
| ABANDONED | https://review.openstack.org/80866 | mikalstill                  | Proposed blueprint for live mi... | 67 days  | 55 days  | v=1 c=-1,-1                   |
| MERGED    | https://review.openstack.org/81381 | jogo                        | Add Apache 2 License              | 65 days  | 63 days  | w=1 v=2 s=1 c=2,1,2           |
...snip....

Personally I’m not too interested in the last updated date, status or owner most of the time, and want things sorted by last updated date. I want to give lots of space for the subject, have approvals to be displayed in colour and only display changes that are open and in the master branch. This can be done using command line arguments but it gets very tedious:

$ gerrymander changes -p openstack/nova-specs \
     --field url --field subject:80 --field createdOn --field approvals \
     --color --branch master --status open --sort createdOn
Changes
-------

+------------------------------------+-------------------------------------------------------------------------------------+----------+--------------------------+
| URL                                | Subject                                                                             | Created  | Approvals                |
+------------------------------------+-------------------------------------------------------------------------------------+----------+--------------------------+
| https://review.openstack.org/80865 | Proposed blueprint for libvirt serial console work in juno.                         | 67 days  | v=-1 c=1,1,-1,-1,-1,-1   |
| https://review.openstack.org/81828 | Scheduler: Adds per-aggregate filters                                               | 63 days  | v=1 c=1,1,-1,1           |
| https://review.openstack.org/82456 | Propose: Normalize Weights (adapt weighers)                                         | 60 days  | v=-1 c=-1                |
| https://review.openstack.org/82584 | Proposed blueprint for libvirt Sheepdog instances.                                  | 59 days  | v=1 c=1,2,1,1            |
...snip....

This output preference can be added to the $HOME/.gerrymander config file directly, avoiding the need to create a wrapper script

[command-changes]
field=url, subject:80, createdOn, approvals
branch=master
sort=createdOn
color=true

With the result that this is now the default

$ gerrymander changes -p openstack/nova-specs 
Changes
-------

+------------------------------------+-------------------------------------------------------------------------------------+----------+--------------------------+
| URL                                | Subject                                                                             | Created  | Approvals                |
+------------------------------------+-------------------------------------------------------------------------------------+----------+--------------------------+
| https://review.openstack.org/80865 | Proposed blueprint for libvirt serial console work in juno.                         | 67 days  | v=-1 c=1,1,-1,-1,-1,-1   |
| https://review.openstack.org/81828 | Scheduler: Adds per-aggregate filters                                               | 63 days  | v=1 c=1,1,-1,1           |
| https://review.openstack.org/82456 | Propose: Normalize Weights (adapt weighers)                                         | 60 days  | v=-1 c=-1                |
| https://review.openstack.org/82584 | Proposed blueprint for libvirt Sheepdog instances.                                  | 59 days  | v=1 c=1,2,1,1            |
...snip....

Now the obvious limitation with setting defaults in the config file is that you might have many different sets of defaults you care about. For example when looking at nova-specs designs, I’d prefer the sorting to be done by subject and don’t really care about the author. The gerrymander config file copes with this too, by allowing you to setup command aliases:

[commands]
aliases=nova-specs, cinder-specs

[alias-nova-specs]
basecmd=changes
help=Nova design specs

[alias-cinder-specs]
basecmd=changes
help=Cinder design specs

These new commands are now first-class citizens on a par with any other built-in commands as far as gerrymander is concerned, so you can then define default settings for them independently.

[command-nova-specs]
project = openstack/nova-specs
status = open
field = url, subject:80, createdOn, approvals
sort = subject
color = true

[command-cinder-specs]
project = openstack/cinder-specs
status = open
field = url, subject:80, createdOn, approvals
sort = subject
color = true

Trying out the new nova-specs command…

$ gerrymander nova-specs
Changes
-------

+------------------------------------+-------------------------------------------------------------------------------------+----------+--------------------------+
| URL                                | Subject                                                                             | Created  | Approvals                |
+------------------------------------+-------------------------------------------------------------------------------------+----------+--------------------------+
| https://review.openstack.org/95054 | API: Live Resize                                                                    | 9 hours  | v=1                      |
| https://review.openstack.org/85726 | API: Metadata Service Callbacks                                                     | 45 days  | v=1 c=1                  |
| https://review.openstack.org/85673 | API: Proxy neutron configuration to guest instance                                  | 24 days  | v=1 c=1                  |
| https://review.openstack.org/94918 | Add Barbican wrapper specification                                                  | 20 hours | v=1                      |
| https://review.openstack.org/94370 | Add LVM ephemeral storage encryption specification                                  | 2 days   | v=1 c=1,1,-1             |
...snip....

This blog post has just looked at the ‘changes’ command, but any gerrymander command can be customized in this way – every single command line option is mapped into the configuration file in the same way.