Re: ❌ FAIL: Stable queue: queue-5.1

[Greg KH <gregkh@linuxfoundation.org>]

On Wed, Jul 03, 2019 at 08:01:16AM -0400, Veronika Kabatova wrote:
> 
> 
> ----- Original Message -----
> > From: "Greg KH" <gregkh@linuxfoundation.org>
> > To: "CKI Project" <cki-project@redhat.com>
> > Cc: "Linux Stable maillist" <stable@vger.kernel.org>
> > Sent: Wednesday, July 3, 2019 1:25:20 PM
> > Subject: Re: ❌ FAIL: Stable queue: queue-5.1
> > 
> > On Wed, Jul 03, 2019 at 07:16:58AM -0400, CKI Project wrote:
> > > Hello,
> > > 
> > > We ran automated tests on a patchset that was proposed for merging into
> > > this
> > > kernel tree. The patches were applied to:
> > > 
> > >        Kernel repo:
> > >        git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
> > >             Commit: 8584aaf1c326 - Linux 5.1.16
> > > 
> > > The results of these automated tests are provided below.
> > > 
> > >     Overall result: FAILED (see details below)
> > >              Merge: FAILED
> > 
> > Guys, this is getting annoying, this is your test systems, the queue is
> > empty :)
> > 
> 
> Hi,
> 
> this is not an empty queue problem (that should be fixed now). We triggered
> the testing right after the 5.1.16 was released to test the present queue
> with it. We have added the commit hash of the queue to the merge details in
> the report to verify this is indeed the case.
> 
> The base commit for the stable kernel is 8584aaf1c326
> The commit of the stable queue is d0f506ba82
> 
> This queue was removed a minute later (obviously with the release) after the
> baseline change was pushed but we caught this combo as we try to trigger
> testing after every change to any of those repos. So the patches from the
> queue really didn't apply.
> 
> 
> I currently see two ways (or their combination) around this:
> 1) The queue changes need to be pushed first

Given that you are working behind a mirror of the "real" git trees, they
can, and probably will, get out of order, so there's no guarantee of
"first" here.

And I am doing this in a scripted way, so they should be pushed within 1
minute of each other at this point in time.

> 2) We detect how long ago the baseline was pushed and if it's less than
>    let's say 5mins we abort the pipeline to give you enough time to do the
>    changes to the repo

I say this is the best thing to do to help with the mirroring issues
involved.

thanks,

greg k-h