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 1FA1043B55; Tue, 20 Feb 2024 16:21:36 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E534A402A7; Tue, 20 Feb 2024 16:21:35 +0100 (CET) Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) by mails.dpdk.org (Postfix) with ESMTP id 4DCA14029B for ; Tue, 20 Feb 2024 16:21:35 +0100 (CET) Received: by mail-ot1-f42.google.com with SMTP id 46e09a7af769-6e4351ce57aso1657387a34.3 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=N5Y5twY+qoRk3f9vdFOIX5GU/OOR3zb9Tgexkb5Kzq3/nQx93dltYIFH1TGgy4w27c ocAPaZnboO0vzqApUaQAxzjzs8finpdvoGu4mWt0GdmBSzd3Jo3+CrvjKg9OOyP1ODZf 4OQPxd+a/O16mgPUEcmWIdinR7HBLuCJ/v5+k4A+N6YwlZ5We5pB5lrtA0lV/DImfpNq 1ARPfX9iEPdTFnpKnsEnjQSvatDiSoy4P57ewD/muCljYaax3UjTf99yEzsiMup2eMwU gsmKFI08kpk8gt/4UwZvkjUE9cFplAhbIj6L/lfebLjL3yQItTfjCi/oYbO3Yv76Bevd N+qQ== X-Gm-Message-State: AOJu0YwjkOJqRpjTYHVdkow9chH6CUc+MCpUVfs9yivd0MY93VHxRNag 4BX6+ZvHTuMUiMxe/Ufwvmcla447wNyAZy59tJghr5Wy3vCID9FnYO06Td0AfEvTTeGoIhDUY40 fl8+4SmG4w/R1uF8QjsWN+PDuECzL/Oh82/pODQ== 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: 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 --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--