On Wed, May 08, 2024 at 05:54:50PM +0000, Chuck Lever III wrote: > > > > On May 8, 2024, at 1:45 PM, Steve French <smfrench@xxxxxxxxx> wrote: > > > > I would be very happy if there were an easy way to do three things > > faster/easier: > > 1) make it easier to run a reasonably large set of fs tests automatically > > on checkin of a commit or set of commits (e.g. to an externally visible > > github branch) before it goes in linux-next, and a larger set > > of test automation that is automatically run on P/Rs (I kick these tests > > off semi-manually for cifs.ko and ksmbd.ko today) > > 2) make it easier as a maintainer to get reports of automated testing of > > stable-rc (or automate running of tests against stable-rc by filesystem type > > and send failures to the specific fs's mailing list). Make the tests run > > for a particular fs more visible, so maintainers/contributors can note > > where important tests are left out against a particular fs > > In my experience, these require the addition of a CI > apparatus like BuildBot or Jenkins -- they are not > directly part of kdevops' mission. Song Liu and Paul E Luse will have a talk on Wednesday about using a CI framework for md/raid. The holy grail I think here is that they have used their experience with eBPF patchwork CI integration, and I think everyone likely wants something similar: https://patchwork.kernel.org/project/netdevbpf/list/ The S / W / F is Success / warning/ fail. I'd like to see how we can do that for kdevops. The work is already put in place to ramp up complex workflows, now we just have to launch them and collect information. > Scott Mayhew and > I have been playing with BuildBot, and there are some > areas where integration between kdevops and BuildBot > could be improved (and could be discussed next week). Neat! > > 3) make it easier to auto-bisect what commit regressed when a failing test > > is spotted > > Jeff Layton has mentioned this as well. I don't think > it would be impossible to get kdevops to orchestrate > a bisect, as long as it has an automatic way to decide > when to use "git bisect {good|bad}" Kent alreeady seems to have this working too, we should try to see what we can leverage. Luis
