Re: RFC: Github PR bot questions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Thu, 2021-06-17 at 08:18 -0600, Rob Herring wrote:
> On Wed, Jun 16, 2021 at 4:33 PM James Bottomley
> <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > On Wed, 2021-06-16 at 15:11 -0600, Rob Herring wrote:
> > > > - subsystem maintainers can configure whatever CI pre-checks
> > > > they want before the series is sent to them for review (and we
> > > > can work on a library of Github actions, so nobody needs to
> > > > reimplement multiple times)
> > > 
> > > What about all the patches that don't come from the GH PR? Those
> > > need CI pre-checks too. We're going to implement CI twice? The
> > > biggest issue I have on CI checks is applying patches. My
> > > algorithm is apply to my current base (last rc1 typically) or
> > > give up. I'm sure it could be a lot smarter trying several
> > > branches or looking at base-commit (not consistently used) or the
> > > git diff treeish hashes. What I'd really like is some bot or
> > > script that's applying series and publishing git branches with a
> > > messageid to git branch tool. 0-day is doing this now. Basically,
> > > the opposite direction as others have mentioned.
> > 
> > I've got to say my experience with Github CIs has been pretty
> > unpleasant.  Pretty much every project I've ever pushed to has had
> > at least one commit reject because of a bug in the CI rather than
> > the commit which they usually dump on the submitter to fix.  As an
> > endless devops make work project, I'm sure they're fine, but what
> > we have now with 0-day is pretty much good enough for most kernel
> > work, plus if it goes wrong we can ignore it and somebody else
> > fixes it ...
> It's the making a git branch somewhere that I'm interested in, not
> the Github part of it. If someone wants to tie GH CI to that and send
> out replies to patches, then fine. We can use them if useful or
> ignore if not.
> 0-day is a bit unpredictable in terms of response time. I often only
> get reports after things land in linux-next which is a bit late IMO.
> What is run and the priorities are all opaque.

You can specifically ask it (or rather it's handlers) to send you or
the mailing list a success report when the tests you've requested have
run.  I think they also respond to triggers (please test this branch

I suspect what we could all do with is a nice how 0-day can work for
you presentation from its handlers so all of us know all of the tricks.


[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux