[all][TC] Stats about rechecking patches without reason given

Ghanshyam Mann gmann at ghanshyammann.com
Thu Jun 30 14:38:20 UTC 2022

 ---- On Thu, 30 Jun 2022 08:37:47 -0500  Sean Mooney <smooney at redhat.com> wrote --- 
 > On Thu, 2022-06-30 at 13:06 +0000, Jeremy Stanley wrote:
 > > On 2022-06-30 14:57:44 +0200 (+0200), Dmitriy Rabotyagov wrote:
 > > > Is it possible to adjust the script a bit in the future to add the
 > > > amount of changes pushed/merged or some ratio of the amount of
 > > > rechecks per merged patch? I think it would also be an interesting
 > > > stat to see in addition to the amount of rechecks to understand how CI
 > > > is stable or not.
 > > [...]
 > > 
 > > Recheck comment volume doesn't really provide an accurate measure of
 > > CI stability, all it tells you is how often people requested
 > > rerunning tests. Their reasons for doing it can be myriad, from not
 > > believing actual failures their changes are causing, to repeatedly
 > > rechecking successful results in hopes of reproducing some rare
 > > failure condition.
 > yep we also recheck succeful result if we think we have fixed an intermint
 > ci failure that we could not repoduced reliably but created a patch based on code inspection.
 > in such a case we usually recheck 3 times looking for at least 3 consecitive check +1s before we +2w
 > rearly is also recheck if a patch is old and the logs have rotaed when im reviewing others work
 > but genrally i just click the rebase button in that case. for example i will tend to do +2 recheck
 > if there are already cherry picks of the patch to avoid those having to be updated. but as i said this is
 > rare as we dont ofthen have bugfixes that sit around for 3+ months that still actully apply with out a merge confilict
 > but it does happen.
 > so recheck is not a a great proxy for ci stablity without knowing the reason which is why not doing bare rechecks is important.

I think having elastic-recheck up again will help us to check the CI stability and what bug is causing more issues.
dpawlik is working on that.

The TC idea about Slawek's script is to keep monitoring the bare recheck and build a culture in all OpenStack projects
about not doing any bare recheck and at least finding out what bug is causing it. With that, we will be getting more attention
to frequent bugs and asking the respective team to fix that.

We in TC will be monitoring the same regularly and post which project is making more bare recheck. We request each project
even your bare recheck is low add this monitoring in your weekly meeting also so that you keep giving the message and monitor too.
I have added the same in QA meeting also.



More information about the openstack-discuss mailing list