Re: Email based retest request process: proposal for new pull/re-apply feature

[Patrick Robb <probb@iol.unh.edu>]

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

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.


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

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.

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