Reject "recheck/reverify bug <the bug# being fixed>"

[Dolph Mathews]

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://status.openstack.org/rechecks/ with bugs apparently affecting just one change (the change that's actually trying to fix the referenced bug).

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/reverifying here would not be a legitimate path forward.

It'd be nice to have jenkins respond with a comment pointing the author to documentation about how to use recheck/reverify correctly ( https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures ), or at least ignore this edge case altogether.

[Clark Boylan (cboylan)]

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.

[James E. Blair (corvus)]

It could be done like the 'require-approval' was done, where we say "in order for this trigger to match, we also require that the commit message match this regex". Something like:

        - event: comment-added
          comment_filter: (?i)^\s*recheck(( (?:bug|lp)[\s#:]*(?P<bugno>\d+))|( no bug))\s*$
          require-commitmsg:
            (?!Closes-Bug: (?P=bugno))

But then we'de have to actually get regex group data from the comment filter regex into the commit message regex, or vice-versa. You'd have to determine ordering, or somehow combine the two regexes and fields.

It seems very complicated, a bit messy, and probably too much work for the benefit.