Gerrit查询API对比：SSH与REST API（pygerrit2）选型、转换及故障排查

两种查询方式的适用场景对比 #

• SSH 命令查询适配场景：
  • 临时在命令行环境快速排查问题，不需要搭建自动化脚本时可直接执行
  • 所在网络开放Gerrit 29418端口SSH访问权限，且无跨系统集成需求的场景
  • 优势是参数简单直观，无需依赖第三方Python模块，手动排查效率更高
• 基于REST API（pygerrit2）适配场景：
  • 需要把Gerrit查询能力集成到Python自动化流程、批量处理脚本的场景
  • 所在网络限制29418端口访问，只能通过常规Web端口访问Gerrit服务的场景
  • 优势是返回的结构化JSON可直接映射为Python原生对象，和后续逻辑处理链路适配性更好，不需要单独维护SSH连接的权限配置
• 选型参考：无绝对优劣区分，单次手动查询优先使用SSH命令，自动化集成场景优先选择pygerrit2的REST实现

SSH查询命令转REST API的规则映射 #

原参考SSH命令：
ssh -p 29418 gerrit.review.com gerrit query --format JSON --current-patch-set status:open MY-JIRA
字段对应关系：

• 查询过滤条件status:open MY-JIRA直接作为REST接口q参数的内容，做URL编码即可
• SSH参数--current-patch-set对应REST接口的输出配置参数o=CURRENT_REVISION，作用是让接口返回结果携带当前补丁集的完整详情，而非默认返回的精简字段

原有REST调用代码的问题修正 #

之前编写的异常代码：

mylst = rest.get("/changes/?q=status:open%20current-patch-set%20{}".format(jira))

存在两个核心问题：

1. 错误将SSH的开关参数current-patch-set当作查询过滤条件拼入q参数，相当于额外要求变更内容匹配“current-patch-set”文本，无法返回正确结果
2. 未添加获取当前补丁集的输出配置参数，即使查询条件正确，返回结果也不会包含完整的当前补丁集信息

修正后的等价调用代码：

mylst = rest.get(f"/changes/?q=status:open+{jira}&o=CURRENT_REVISION")

注：REST接口中查询条件内的空格使用+或%20做URL编码均可，上述代码直接拼接对应JIRA单号即可匹配关联的变更。

内容的提问来源于stack exchange，提问作者lucky1928