<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Also it can be useful to run daily sub-tree testing by request, if possible. </blockquote><div> </div><div>That wouldn't be too difficult. I'll make a ticket for this. Although, for testing on the daily sub-trees, since that's UNH-IOL specific, that wouldn't necessarily have to be done via an email based testing request framework. We could also just add a button to our dashboard which triggers a sub-tree ci run. That would help keep narrow the scope of what the email based retesting framework is for. But, both email or a dashboard button would both work. </div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 6, 2023 at 1:53 PM Ferruh Yigit <<a href="mailto:ferruh.yigit@amd.com">ferruh.yigit@amd.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/6/2023 5:56 PM, Patrick Robb wrote: > Hello all, > > I'd like to revive the conversation about a request from the community > for an email based re-testing framework. The idea is that using one > standardized format, dpdk developers could email the test-report mailing > list, requesting a rerun on their patch series for "X" set of tests at > "Y" lab. I think that since patchwork testing labels (ie. > iol-broadcom-Performance, github-robot: build, loongarch-compilation) > are already visible on patch pages on patchwork, those labels are the > most reasonable ones to expect developers to use when requesting a > re-test. We probably wouldn't want to get any more general than that, > like, say, rerunning all CI testing for a specific patch series at a > specific lab, since it would result in a significant amount of "wasted" > testing capacity. > > The standard email format those of us at the Community Lab are thinking > of is like below. Developers would request retests by emailing the > test-report mailing list with email bodies like: > > [RETEST UNH-IOL] > iol-abi-testing > iol-broadcom-Performance > > [RETEST Intel] > intel-Functional > > [RETEST Loongson] > loongarch-compilation > > [RETEST GHA] > github-robot: build > > From there, it would be up to the various labs to poll the test-report > mailing list archive (or use a similar method) to check for such > requests, and trigger a CI testing rerun based on the labels provided in > the re-test email. If there is interest from other labs, UNH might also > be able to host the entire set of re-test requests, allowing other labs > to poll a curated list hosted by UNH. One simple approach would be for > labs to download all emails sent to test-report and parse with regex to > determine the re-test list for their specific lab. But, if anyone has > any better ideas for aggregating the emails to be parsed, suggestions > are welcome! If this approach sounds reasonable to everyone, we could > determine a timeline by which labs would implement the functionality > needed to trigger re-tests. Or, we can just add re-testing for various > labs if/when they add this functionality - whatever is better. Happy to > discuss at the CI meeting on Thursday. > +1 to re-testing framework. Also it can be useful to run daily sub-tree testing by request, if possible. </blockquote></div> <div> </div>-- <div dir="ltr" class="gmail_signature"><div dir="ltr">Patrick RobbTechnical Service ManagerUNH InterOperability Laboratory21 Madbury Rd, Suite 100, Durham, NH 03824<a href="http://www.iol.unh.edu/" style="color:rgb(17,85,204)" target="_blank">www.iol.unh.edu</a> <img src="https://lh4.googleusercontent.com/7sTY8VswXadak_YT0J13osh5ockNVRX2BuYaRsKoTTpkpilBokA0WlocYHLB4q7XUgXNHka6-ns47S8R_am0sOt7MYQQ1ILQ3S-P5aezsrjp3-IsJMmMrErHWmTARNgZhpAx06n2" width="150" height="37" style="border: none;"></div></div>