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 B6E1443B9B; Mon, 4 Mar 2024 16:22:01 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 452F240A7D; Mon, 4 Mar 2024 16:22:01 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 7FE174027D for ; Mon, 4 Mar 2024 16:21:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709565719; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jyES+siZ2d4eK+1sU76OKzUd5v3qFr38tsV0v9CaJ/g=; b=G2ieMQZG7sPHwHoCX0EERpH7lt0QCEt+sqVscbdrX7yWsGJ644uOvLyeOp4TyizTADfkC3 wrphyN32rFNJE3eAqI+6+8lFmxLiAQeFImDqNLONYnBChFnRnA1fR6PPMvxRq7OdaxT+Q5 c/Zq0kmkXF3RXDryklGQfm4kUXJevf8= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-217-kzvlUYq7O1Wx5L_aSRlQ3Q-1; Mon, 04 Mar 2024 10:21:55 -0500 X-MC-Unique: kzvlUYq7O1Wx5L_aSRlQ3Q-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2B6F91C0BA44; Mon, 4 Mar 2024 15:21:55 +0000 (UTC) Received: from RHTPC1VM0NT (unknown [10.22.32.192]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2AF60492BE2; Mon, 4 Mar 2024 15:21:54 +0000 (UTC) From: Aaron Conole To: zhoumin Cc: Patrick Robb , ci@dpdk.org, dev@dpdk.org Subject: Re: Email based retest request process: proposal for new pull/re-apply feature References: <2640cd5b-ea3d-cd74-d5c0-eb776e880b13@loongson.cn> Date: Mon, 04 Mar 2024 10:21:53 -0500 In-Reply-To: <2640cd5b-ea3d-cd74-d5c0-eb776e880b13@loongson.cn> (zhoumin@loongson.cn's message of "Fri, 1 Mar 2024 22:36:00 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org zhoumin writes: > On Wed, Feb 21, 2024 at 2:24AM, Patrick Robb wrote: > > On Tue, Feb 20, 2024 at 1:12=E2=80=AFPM Aaron Conole wrote: > > Why not something like: > > Recheck-request: [attribute-list],[test-list]... > > For example, then we can do: > > Recheck-request: rebase=3D[identifier],.... > > where identifier is a branch specifier (or the word 'latest')? > > I hadn't thought about the option of allowing branch specifiers. Agree t= hat allowing a human correction process for > the pw_maintainer_cli.py script choosing the wrong branch sounds helpful= . > > My original idea was offering 2 options (test original artifact, or re-a= pply on latest). Do we want to support for > checking out to a specific commit and re-applying there? I figured that = would not be worth it (too much of a niche > case), but your comments are making me reconsider.=20 > > I agree with you that allowing developers to correct the target branch is= useful. But, the developer should just provide > the name of branch instead of commit ID, which is more reasonable. Of cou= rse, the rebasing option is more important. > So, I consider we can allow developers to submit a request as following f= ormat: > > Recheck-request: rebase=3DTrue|branch=3Dmain|contexts=3Diol-compile-amd64= -testing, iol-broadcom-Performance,... > > We can use "|" as the separator, for example. `rebase` and `branch` can b= e optional and we can use the default values > if the developer doesn't provide them. The default is not rebasing for `r= ebase` option. The default is the branch chosen > by pw_maintainer_cli.py script for `branch` option. The `contexts` option= is required. Interesting approach. But I don't know about contexts=3D or something like that. It means there are two passes through the regex. Also, I don't know about contexts either - if the series was requested to rebase, every lab that can re-test probably should since the results aren't going to be valid from the old tests. > Just spit-balling on syntax. > > That said, I agree - if a rebase has been requested, all tests need to > be rerun. Maybe we should consider that the test labels should be added > with a run number or something? Or we could also include that the run > is a rerun. That way for labs that don't currently support the recheck > request framework, we can easily tell that they weren't re-tried. > > so re-report with a modified test label? That is good in that it shows t= he behavior more clearly. But, it also means > we will not overwrite any fails. So the fail will still be there, and th= e patchwork patch page will grow a huge table. > Maybe this is fine. =20 > > Re-report with a modified test label may be better. That can tell people = more information about the CI testings, such as > that the retest indeed happened. Just back from PTO - actually, I don't think we need to adjust the label, but rather the description. That would allow the mechanism that overwrites the existing test to keep the "checks" page tidy, but also making the retest information clear. WDYT? > Also raises the point of getting more coverage for the retest framework = at other labs. I will email Min Zhou > regarding how he uses the dpdk-ci project for the loongson build jobs an= d see how well that can integrate with the > get_reruns.py script. That would be great!