<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">What would be the purpose of [RETEST UNH-IOL]? </blockquote><div>Agreed, this is redundant, provided we will be using the labels/contexts used on patchwork. That seems to be the idea behind Aaron's proposed format and I think we should move to use his format since it previously reached some consensus, and appears to be easy to parse.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We need to specify the patchwork identifier of the patch. We could make a script similar to the checkpatch run on <a href="http://dpdk.org/" rel="noreferrer" target="_blank">dpdk.org</a>: <a href="https://git.dpdk.org/tools/dpdk-ci/tree/tests/checkpatch.sh" rel="noreferrer" target="_blank">https://git.dpdk.org/tools/dpdk-ci/tree/tests/checkpatch.sh</a> The easiest way to run it is to make the script as the receiver of the mail. If the lab can receive the mails from the mailing list, then just need to filter the retest requests for its own lab.</blockquote><div>Yes, I think this is reasonable. I don't think this process is likely to change much, and if we can provide a script to live on the dpdk-ci repo which checks for retest requests, we can reasonably expect the labs to separately set up an environment to handle running that script and triggering their re-tests. Thanks Thomas. </div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 7, 2023 at 8:53 AM Aaron Conole <<a href="mailto:aconole@redhat.com">aconole@redhat.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">Patrick Robb <<a href="mailto:probb@iol.unh.edu" target="_blank">probb@iol.unh.edu</a>> writes: > Also it can be useful to run daily sub-tree testing by request, if possible. > > 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. We had discussed this long ago - including agreeing on a format, IIRC. See the thread starting here: <a href="https://mails.dpdk.org/archives/ci/2021-May/001189.html" rel="noreferrer" target="_blank">https://mails.dpdk.org/archives/ci/2021-May/001189.html</a> The idea was to have a line like: Recheck-request: <test names> where <test names> was the tests in the check labels. In fact, what started the discussion was a patch for the pw-ci scripts that implemented part of it. I don't see how to make your proposal as easily parsed. WDYT? Can you re-read that thread and come up with comments? > On Tue, Jun 6, 2023 at 1:53 PM Ferruh Yigit <<a href="mailto:ferruh.yigit@amd.com" target="_blank">ferruh.yigit@amd.com</a>> wrote: > > 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>