Hi Patrick,
I'm sorry for this serious delay.
I do believe that retesting is meaningful and Loongson lab should
support it. Meanwhile, the email based retest framework is
wonderful and it is not too hard to integrate the retest function
into the existed dpdk-ci framework. Although I am responsible for
the Loongson lab, I'm not full-time on it. So, I need some time to
support the email based retest function in Loongson lab. It may
take a few weeks.
And I forgot to mention, you can set up part of this using the dpdk-ci project get_reruns.py script. It polls the Rest API for all comment on patch emails events in a given timeframe, and uses regex to write a json file containing any retest requests from that period. We run this periodically (every 15 minutes) at UNH using Jenkins, but I think you could do this with a cron job or another solution.
Just remember to keep bringing the timeframe parameters forward or you will end up consuming a retest request more than once!
Thanks for pointing it out. This script is very useful and it can help us more easily support the retest function.
But, I got an empty output when I tried to get the retest requests since 2023-08-01 as following:
# python3 tools/get_reruns.py -ts 2023-08-01 --contexts
"iol-compile-amd64-testing,iol-broadcom-Performance,iol-unit-arm64-testing,github-robot"
{
"retests": {},
"last_comment_timestamp": "2024-02-28T02:27:49.500680"
}
Or am I using this script wrong?
On Thu, Feb 22, 2024 at 12:55 AM Patrick Robb <probb@iol.unh.edu> wrote:
Hi Zhoumin,
I wanted to reach out to you about the possibility of adding the Loongson lab to the group of labs supporting the email based retest framework. Currently, the UNH Community Lab and also the GitHub Robot are supporting patch retest requests from emails, and we would like to extend that to all the publicly reporting CI labs, if possible.
For context, the original announcement:https://inbox.dpdk.org/ci/CAC-YWqiXqBYyzPsc4UD7LbUHKha_Vb3=Aot+dQomuRLojy2hvA@mail.gmail.com/
Aaron announcing support for the github robot: https://inbox.dpdk.org/ci/f7tedfooq6k.fsf@redhat.com/
And the retest framework definition on the dpdk.org testing page: https://core.dpdk.org/testing/#requesting-a-patch-retest
So a format like:
Recheck-request: iol-compile-amd64-testing, iol-broadcom-Performance, iol-unit-arm64-testing, github-robot
Is current accepted, and it would be great if we could add Loongson support to the list too. What we are supporting right now is doing retesting on the original DPDK artifact created for a patch when that patch was submitted. But we are also thinking of adding in rebasing off of tip of branch as a v2 feature.
I think the stateless retesting is more easily to implement the
retest function.
I wrote a script to report the CI failures from Loongson lab
three times a day by fetching the test results from
patches.dpdk.org. This script can help me find the CI failures in
time. So, sometimes I manually triggered the DPDK CI test in
Loongson lab as a retest for some patches or series when I found
there is a test failure caused by Loongson lab self. In this case,
the retest follows the routines of normal test. So, it will always
do rebasing before applying the patches or series when do this
kind of retest.
I think it is simpler for Loongson lab to implement the retest
function. I think it is also feasible to do the retesting on the
original DPDK artifact created for a patch when that patch was
submitted. But, I need some times to reconstruct the existed
routines.
How do you think of it?
Best Regards,
Min Zhou
Does this sound possible for the Loonson lab? I know you are leveraging the dpdk-ci repo for standing up your CI testing, but I don't know specifically whether that lends itself well towards doing retests later, or if that would be a big technical challenge. Let me know!
If it is possible for the Loongson lab, maybe we can discuss in the March 7 CI Testing meeting?
--
Patrick Robb
Technical Service Manager
UNH InterOperability Laboratory
21 Madbury Rd, Suite 100, Durham, NH 03824
