Indeed, I was going to send out an email about pre-commit filtering, but
we've already found some kinks and may need to revert it.
The change was submitted in PR#5611  and enables Jenkins triggering to
only run pre-commits based on modified files. However, Udi noticed that
this also prevents manually running pre-commits on a PR with trigger
phrases when your PR changes don't match the pre-commit include path .
This was blocking 2.5.0 release validation, so I have a PR out to revert
the change .
I did some investigation and this is a deficiency in the Jenkins plugin
used to trigger jobs on pull requests. I've filed a bug  and submitted a
PR , but there's no guarantee that it'll get accepted or when it will be
Question for others: we were hoping to enable pre-commit triggering as an
optimization to decrease testing wait time and limit the impact of test
flakiness . But this bug in the plugin means we'd lose the ability to
manually trigger pre-commits which aren't automatically run. One workaround
would be to run the tests locally instead of on Jenkins, though that's
clearly less desirable. Is this a blocker?
(a) Keep pre-commit triggering enabled for now and hope the upstream patch
gets accepted, or
(b) Revert the pre-commit change and wait for the patch
On Wed, Jun 13, 2018 at 10:03 PM Rui Wang <[EMAIL PROTECTED]> wrote: