DPDK patches and discussions
 help / color / mirror / Atom feed
From: Patrick Robb <probb@iol.unh.edu>
To: ci@dpdk.org
Cc: dev@dpdk.org, Aaron Conole <aconole@redhat.com>,
	zhoumin <zhoumin@loongson.cn>
Subject: Email based retest request process: proposal for new pull/re-apply feature
Date: Tue, 20 Feb 2024 10:21:23 -0500	[thread overview]
Message-ID: <CAJvnSUBp7gZfarfWN05-Td=QPSzNtQWztdEY820gGPm98K4QAA@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1990 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 2178 bytes --]

             reply	other threads:[~2024-02-20 15:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-20 15:21 Patrick Robb [this message]
2024-02-20 18:12 ` Aaron Conole
2024-02-20 18:24   ` Patrick Robb
2024-03-01 14:36     ` zhoumin
2024-03-04 15:21       ` Aaron Conole
2024-03-07 17:06         ` Adam Hassick
2024-03-18 15:59           ` Patrick Robb
2024-03-19  8:36             ` zhoumin
2024-03-19 17:30               ` Patrick Robb
2024-03-19 17:53                 ` Aaron Conole
2024-03-20  1:35                 ` zhoumin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJvnSUBp7gZfarfWN05-Td=QPSzNtQWztdEY820gGPm98K4QAA@mail.gmail.com' \
    --to=probb@iol.unh.edu \
    --cc=aconole@redhat.com \
    --cc=ci@dpdk.org \
    --cc=dev@dpdk.org \
    --cc=zhoumin@loongson.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).