DPDK CI discussions
 help / color / mirror / Atom feed
From: Aaron Conole <aconole@redhat.com>
To: zhoumin <zhoumin@loongson.cn>
Cc: Patrick Robb <probb@iol.unh.edu>,  ci@dpdk.org,  dev@dpdk.org
Subject: Re: Email based retest request process: proposal for new pull/re-apply feature
Date: Mon, 04 Mar 2024 10:21:53 -0500	[thread overview]
Message-ID: <f7tbk7uc99q.fsf@redhat.com> (raw)
In-Reply-To: <2640cd5b-ea3d-cd74-d5c0-eb776e880b13@loongson.cn> (zhoumin@loongson.cn's message of "Fri, 1 Mar 2024 22:36:00 +0800")

zhoumin <zhoumin@loongson.cn> writes:

> On Wed, Feb 21, 2024 at 2:24AM, Patrick Robb wrote:
>
>  On Tue, Feb 20, 2024 at 1:12 PM Aaron Conole <aconole@redhat.com> wrote:
>
>  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')?
>
>  I hadn't thought about the option of allowing branch specifiers. Agree that 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-apply 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. 
>
> 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 course, the rebasing option is more important.
> So, I consider we can allow developers to submit a request as following format:
>
> Recheck-request: rebase=True|branch=main|contexts=iol-compile-amd64-testing, iol-broadcom-Performance,...
>
> We can use "|" as the separator, for example. `rebase` and `branch` can be optional and we can use the default values
> if the developer doesn't provide them. The default is not rebasing for `rebase` 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= 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 the behavior more clearly. But, it also means
>  we will not overwrite any fails. So the fail will still be there, and the patchwork patch page will grow a huge table.
>  Maybe this is fine.  
>
> 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 and see how well that can integrate with the
>  get_reruns.py script.

That would be great!


  reply	other threads:[~2024-03-04 15:22 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
2024-02-20 18:24   ` Patrick Robb
2024-03-01 14:36     ` zhoumin
2024-03-04 15:21       ` Aaron Conole [this message]
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=f7tbk7uc99q.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).