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.
