From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7CB0243C19; Wed, 28 Feb 2024 06:34:59 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5E5D44027D; Wed, 28 Feb 2024 06:34:59 +0100 (CET) Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by mails.dpdk.org (Postfix) with ESMTP id C00EE4003C for ; Wed, 28 Feb 2024 06:34:57 +0100 (CET) Received: from loongson.cn (unknown [10.20.42.74]) by gateway (Coremail) with SMTP id _____8BxTOn9xd5l5j8SAA--.36479S3; Wed, 28 Feb 2024 13:34:54 +0800 (CST) Received: from [10.20.42.74] (unknown [10.20.42.74]) by localhost.localdomain (Coremail) with SMTP id AQAAf8CxZMz1xd5l+oJJAA--.4748S3; Wed, 28 Feb 2024 13:34:47 +0800 (CST) Subject: Re: Email based retests for the Loongarch lab To: Patrick Robb Cc: ci@dpdk.org, Aaron Conole , David Marchand References: From: zhoumin Message-ID: Date: Wed, 28 Feb 2024 05:34:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux loongarch64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5678840C92E32F38D4217726" Content-Language: en-US X-CM-TRANSID: AQAAf8CxZMz1xd5l+oJJAA--.4748S3 X-CM-SenderInfo: 52kr3ztlq6z05rqj20fqof0/1tbiAQABAWXdnWUG3gABsY X-Coremail-Antispam: 1Uk129KBj93XoWxZFyDGr1fZw15XrWUXF15WrX_yoWrCFW5pa yrta43tryDXF1xA3s7tw40vryakFZ3Jay3tay5J348urn8GFyktrWSkF4Yv3yxCrs3Wrn0 va18Zw1F93WDZFXCm3ZEXasCq-sJn29KB7ZKAUJUUUU8529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3fc02F40Ex7xS67I2xxkvbII20VAFz48EcVAYj2Uv73VFW2AGmfu7bjvj m3AaLaJ3UjIYCTnIWjp_UUUYL7kC6x804xWl14x267AKxVWUJVW8JwAFc2x0x2IEx4CE42 xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUXVWUAwA2ocxC64kIII0Yj41l84x0c7CE w4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26r1j6r1xM28EF7xvwVC0I7IYx2IY6x kF7I0E14v26r1j6r4UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE c7CjxVAFwI0_Gr1j6F4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc804VCY07AIYIkI8V C2zVCFFI0UMc02F40Ex7xS67I2xxkvbII20VAFz48EcVAYj21lYx0E2Ix0cI8IcVAFwI0_ JrI_JrylYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwI xGrwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY0x0E wIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r106r1rMI8I3I0E74 80Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0 I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04 k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7Cj xVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU14rW5UUUUU== X-BeenThere: ci@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK CI discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ci-bounces@dpdk.org This is a multi-part message in MIME format. --------------5678840C92E32F38D4217726 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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. On Thu, Feb 22, 2024 at 1:54PM, Patrick Robb wrote: > 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! > > https://git.dpdk.org/tools/dpdk-ci/tree/tools/get_reruns.py 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 > 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 > > www.iol.unh.edu > > > --------------5678840C92E32F38D4217726 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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.

On Thu, Feb 22, 2024 at 1:54PM, Patrick Robb wrote:
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. 


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

www.iol.unh.edu


--------------5678840C92E32F38D4217726--