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

Sean Mooney smooney at redhat.com
Thu Jun 30 13:37:47 UTC 2022

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.

More information about the openstack-discuss mailing list