+1 to get rid of the "admins very patch" comments if we can. They add no value at all when commented in quadruplicate immediately after PR creation.
On Thu, Jun 30, 2022, 8:40 AM Danny McCormick <[email protected]> wrote: > Hey everyone, I've been digging into the issues we've been having with > Jenkins recently[1] which led to us disabling many of our build > comment triggers (e.g. "Run <job name>" triggering a Jenkins job). Moving > forward, I'd like to recommend that we: > > 1) Try to disable the "Can one of the admins verify this patch?" comments > via the Jenkins plugin configuration. > 2) Add trusted repeat contributors to the Jenkins allow-list. > 3) Try re-enabling all build triggers. > > *Justification* > > Right now, around 33% of our PR comments are "Can one of the admins > verify this patch?". Aside from being (IMO) very unhelpful and annoying, > these are actually causing a significant amount of load on the ghprb plugin > and indicate that these PRs are more expensive than those from allow-listed > contributors. Since we believe that the ghprb plugin makes calls to GitHub > that are roughly proportional to <the number of pr comments>X<the number of > build triggers>, reducing our number of issue comments and the load per > comment should give us enough breathing room to enable our triggers again. > > I wrote up a more thorough supporting doc here as well - - > https://docs.google.com/document/d/15CILeNjNxCnbigSvxNq4eXPj6x6sn5DGdbTdWu55kCI/edit?usp=sharing > > *Disclaimer* > > It's really hard to empirically prove any of this after the fact - I think > there's enough evidence to try it, but we should be ready to engage Infra > to restart Jenkins and ready to revert any triggers we add. > > Thanks, > Danny > > [1] Context on previous investigation here - > https://docs.google.com/document/d/10qyUsvB_uVy5jftfTiwohlvN8Qwix5AuadssyoC4JsE/edit?usp=sharing >
