Hi Aaron,

For planning, we have this on our development schedule in the community lab for the "Q3 Sprint" so that would likely happen during the second half of the summer. I don't think we had any specific comments on the mail / request syntax. I think a lot more of the devils are in the details around storing off the information like message IDs, etc. As well as how long we're looking for retest requests, i.e. the "active" patches, etc.

Cheers,
Lincoln

On Fri, May 21, 2021 at 5:38 AM David Marchand <david.marchand@redhat.com> wrote:

On Thu, May 20, 2021 at 11:05 PM Aaron Conole <aconole@redhat.com> wrote:
> David Marchand <david.marchand@redhat.com> writes:
>
> > On Wed, May 19, 2021 at 4:18 PM Aaron Conole <aconole@redhat.com> wrote:
> >>
> >> ENOTREADY: Missing the actual recheck logic... needs some input /
> >> design before committing to anything.
> >>
> >> When a developer wants to ask for a test case recheck (for example,
> >> maybe to rerun the github-actions test suite), we scan for the specific
> >> line:
> >>
> >> ^Recheck-request: .*$
> >>
> >> The line would break up as:
> >>
> >> Recheck-request: [context]
> >>
> >> where '[context]' is the name of the check (as it appears in the UI).
> >> For example, if we look at a patch that has 'github-robot', we can
> >> request a recheck of the series by sending an email reply with the line:
> >
> > It could happen that the tree was broken and we want to rerun all or a
> > list of tests.
> > Coud we accept multiple ^Recheck-request lines?
>
> I guess we can solve this with the comma separated list.

Yes, it looks fine.

>
> > Or maybe have a magic "all" context?
>
> That might require more thought, but it's possible. Do you think it
> would be better than doing a comma separated list?

No, an explicit list is actually better.
When a new check is added, for someone looking at the mails (maybe 2/3
weeks later), and reading just "all", he would have to know what
checks were available at the time.

--
David Marchand