On Mon, Feb 8, 2021 at 3:50 AM Sunny Kumar <sunkumar@xxxxxxxxxx> wrote: > > Hi Folks, > > I am working on GitHub action based automation for running teuthology > on some batch of PRs. > > Following step describes this workflow: > > Step 1: Once any PR passes necessary checks( make etc) a newly > introduced label `next` can be assigned to PR. > > Step 2: The `next` labeled PRs will be batched together and scheduled > for the next teuthology run. > > The collected labels from all the batched PRs will be used for > selecting the teuthology suite. > Having said that, there are two options to batch and schedule a tethology run: > 1. Batch all patch together > 2. Batch patch component wise > > Both of the above options have their pros and cons one being the high > number of teuthology jobs per run if batched together and more number > teuthology runs if batched component wise. It's not really the number of scheduled suite runs that matter, but the total number of jobs. I'm inclined to think runs should be batched together based on the component/suites they need to run through, since we try to cross-pollinate the QA to catch obvious errors which cross component boundaries, and non-obvious ones can be caught in master integration. I'm curious about the intention here, though -- do we expect all QA runs to eventually be scheduled this way? If so, that sounds GREAT, but for ease of error bisection we probably want to limit the number of PRs which are batched together, or have some way to differentiate between low- and high-risk changes so that we can push simpler things through ASAP without them getting stuck behind more invasive patches that cause test issues. -Greg > > Please, let me know which option is good to go ahead with and if there > are ways to improve it. > > /sunny > _______________________________________________ > Dev mailing list -- dev@xxxxxxx > To unsubscribe send an email to dev-leave@xxxxxxx > _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
