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

Patrick Robb <probb@iol.unh.edu> writes:

> 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.

Why not something like:

Recheck-request: [attribute-list],[test-list]...

For example, then we can do:

Recheck-request: rebase=[identifier],....

where identifier is a branch specifier (or the word 'latest')?

That lets us fixup if the branch picker script guessed a wrong branch.

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.


  reply	other threads:[~2024-02-20 18:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-20 15:21 Patrick Robb
2024-02-20 18:12 ` Aaron Conole [this message]
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=f7t4je3dmya.fsf@redhat.com \
    --to=aconole@redhat.com \
    --cc=ci@dpdk.org \
    --cc=dev@dpdk.org \
    --cc=probb@iol.unh.edu \
    --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).