Reject "recheck/reverify bug <the bug# being fixed>"
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Core Infrastructure |
Invalid
|
Low
|
Unassigned |
Bug Description
I can't think of a use case for anyone using "recheck/reverify bug <the bug# being fixed>" when the commit message explicitly uses Closes-Bug. This appears to be a fairly common misunderstanding of the recheck/reverify syntax, resulting in noise on http://
For example, if a review is trying to fix bug #123, and "recheck bug 123" is performed, then clearly the fix was a failure and it needs a revised patchset (or the commenter is misunderstanding the recheck/reverify syntax). Rechecking/
It'd be nice to have jenkins respond with a comment pointing the author to documentation about how to use recheck/reverify correctly ( https:/
description: | updated |
Changed in openstack-ci: | |
assignee: | nobody → Ricardo Carrillo Cruz (rcarrillocruz) |
Changed in openstack-ci: | |
assignee: | Ricardo Carrillo Cruz (rcarrillocruz) → nobody |
Changed in openstack-ci: | |
status: | Triaged → Invalid |
This would be a good thing to add to the recheck magic. Unfortunately, it may require adding some openstack specific sauce to zuul (rechecks are currently implemented as normal zuul triggers, nothing special about them).
A different alternative would be to have a special recheck/reverify daemon that wasn't zuul that could listen to the Gerrit event stream to make more intelligent decisions about what action to take on these comments. It could then trigger jobs via zuul or gearman. Probably need to discuss this with Jeblair to get a feel for the direction he sees zuul taking.