On Wed, Jul 03, 2019 at 08:01:16AM -0400, Veronika Kabatova wrote: > > > ----- Original Message ----- > > From: "Greg KH" <gregkh@xxxxxxxxxxxxxxxxxxx> > > To: "CKI Project" <cki-project@xxxxxxxxxx> > > Cc: "Linux Stable maillist" <stable@xxxxxxxxxxxxxxx> > > 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
