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

[Patrick Robb]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/dev/attachments/20240220/8975dc37/attachment.htm>