----- 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 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 Maybe you also have a different idea that would work better? We try to keep up with your quick changes to really test everything and in this case ended up being too fast. Thanks for the feedback and working with us so we can figure out a workflow that works the best for you, Veronika > thanks, > > greg k-h > >
