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 206BD43B57; Tue, 20 Feb 2024 16:21:37 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 15EC54064C; Tue, 20 Feb 2024 16:21:37 +0100 (CET) Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) by mails.dpdk.org (Postfix) with ESMTP id 718A2402A7 for ; Tue, 20 Feb 2024 16:21:35 +0100 (CET) Received: by mail-ot1-f43.google.com with SMTP id 46e09a7af769-6dc8b280155so3312831a34.0 for ; Tue, 20 Feb 2024 07:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1708442494; x=1709047294; darn=dpdk.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=bCTA+9GrFfSodD+GDOkNnFlm72WA4FP1JvVQiLeu7Lc=; b=B/5q/79nUgsEDpRW/gv/b9JdR6ZVtheAauZ13rM8lR8GSuPO/NxjNbSNDiREXaDe0R f2QP2zxefLewvF941j/lyvXmeBgw36nl0+BCyzrjyAq7i/l/8jxU8VXHDnBaYYHsy50A tubX0Yr4HRWZLlVvCizGmRWe4RjBnwSemt7rY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708442494; x=1709047294; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=bCTA+9GrFfSodD+GDOkNnFlm72WA4FP1JvVQiLeu7Lc=; b=xF4TX87KVQ8Hwi9hUWAkzgXFSzfLwl8ox3wb45rr6VH3diIDNKRTFdvpcXbIJRacWY vxJokaIh7C8Wls3hpPiPOE/2NyRIPoZUeSdm24kZSuaxV688mbyfKAkcT9nwJ60O5WRQ n2UXXuko/Z/RyyXPGOPRtZhaCBp4aj2V42pU0sg+eg2xCmn2xka3qvGI9AudRzp6UtsS 2rb8iph01rc/H3IuW3oOO3gA9xD2nK0fquWNWwvSyllifZcBBWBq+F5RBrxd2GgNcOPn jQwkzrpzA2/iB3qxp2XpA03K6wOK1FbeJYNcaaR0gy2TmluLPR+P0v9niPabtg9+Dt4B imQg== X-Gm-Message-State: AOJu0YxMm3wpyM6kxFvSb7iW6GxXUw91SysXT8Yn2ADeEEulhkhmodsS J6c7Xw/TLGoUalhgSZHYXFjgqggI3/U0rJp6WI3SDOU2o8DAH4cDUEDPRx8gojZ2g3linfJkipd posvJJZCCVCi1q9TQvh2RAGegxR4QievAGS0ID4vMSqQEt5MZiV4cIA== X-Google-Smtp-Source: AGHT+IHzUyP8/Om8uFuFoby8YPKJfsAgJ3h4yXfGVslLnBykK89cHD2usGHK7Ycbcnf7zAF2JCj6HYONPma+EsLK08I= X-Received: by 2002:a05:6830:160a:b0:6e2:dccd:2cbf with SMTP id g10-20020a056830160a00b006e2dccd2cbfmr14012286otr.4.1708442494427; Tue, 20 Feb 2024 07:21:34 -0800 (PST) MIME-Version: 1.0 From: Patrick Robb Date: Tue, 20 Feb 2024 10:21:23 -0500 Message-ID: Subject: Email based retest request process: proposal for new pull/re-apply feature To: ci@dpdk.org Cc: dev@dpdk.org, Aaron Conole , zhoumin Content-Type: multipart/alternative; boundary="000000000000fffadd0611d1c3fc" 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 --000000000000fffadd0611d1c3fc Content-Type: text/plain; charset="UTF-8" Hi all, I want to poll the CI group and dev community about a proposed feature addition to the CI retest request framework. Currently, you can respond to a patchseries or patch email, requesting a retest like so: Recheck-request: iol-compile-amd64-testing, iol-unit-amd64-testing Labs who have added this functionality (UNH and the GitHub Robot) will then trigger retests according to the contexts provided, using the ORIGINAL dpdk artifact they produced at the time when the patch was submitted. This is useful for requesting a retest on a patch when you believe a failure may have been an infra failure or spurious. It is not useful if you believe the tree your patch was applied on was in a bad state when your patch was submitted, and you would like for your patch to be re-applied on the current tip of the branch. A few people have suggested we add this feature (re-apply to tip of branch and retest). So, we should probably add an option allowing people to indicate they want this behavior instead of the "default" retest. Ferruh emailed me about this a while ago and proposed the following syntax, which I am okay with: Recheck-request,attribute=value: ... So a practical example would look like: Recheck-request,pull=True: iol-sample-apps-testing, iol-compile-amd64-testing, github-robot Also, I believe that although we should still require people to include the contexts they're requesting a retest for for posterity (so we can refer back to it), I think if someone includes the pull keyword, ALL labs should trigger retests for ALL tests. The reason for this is I don't think we should display results side by side on a patchseries which are coming from distinct DPDK artifacts. Readers may assume (rightly, in my opinion) that when they're looking at a results table for a patchseries, those results are all coming from identical DPDK artifacts, and not from distinct DPDK artifacts produced at different times, from different commits. What do you all think? Thanks. --000000000000fffadd0611d1c3fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I want to poll the CI group and dev communi= ty about a proposed feature addition to the CI retest request framework. Cu= rrently, you can respond to a patchseries or patch email, requesting a rete= st like so:

Recheck-request: iol-compile-amd64-testing, iol-unit-amd= 64-testing=C2=A0 =C2=A0=C2=A0

Labs who have added this functionality= (UNH and the GitHub Robot) will then trigger retests according to the cont= exts provided, using the ORIGINAL dpdk artifact they produced at the time w= hen the=C2=A0patch was submitted.=C2=A0

This is useful for requestin= g a retest on a patch when you believe=C2=A0a failure may have been an infr= a failure or spurious. It is not useful if you believe the tree your patch = was applied on was in a bad state when your patch was submitted, and you wo= uld like for your patch to be re-applied on the current tip of the branch. = A few people have suggested we add this=C2=A0feature (re-apply to tip of br= anch and retest). So, we should probably add an option allowing people to i= ndicate they want this behavior instead=C2=A0of the "default" ret= est.=C2=A0

Ferruh emailed me about this a while ago and proposed the= following syntax, which I am okay with:

Recheck-request= ,attribute=3Dvalue: ...

So a practical example wou= ld look like:

Recheck-request,pull=3DTrue: iol-sample-apps-testing, = iol-compile-amd64-testing, github-robot

Also, I believe that althoug= h we should still require people to include the contexts they're reques= ting a retest=C2=A0for for posterity (so we can refer back to it), I think = if someone includes the pull keyword, ALL labs should trigger retests for A= LL tests. The reason for this is I don't think we should display result= s side by side on a patchseries which are coming from distinct DPDK artifac= ts. Readers may assume (rightly, in my opinion) that when they're looki= ng at a results table for a patchseries, those results are all coming from = identical DPDK artifacts,=C2=A0and not from distinct DPDK artifacts produce= d at different times, from different commits.

What do you all think?= Thanks.

--000000000000fffadd0611d1c3fc--