Re: Email Based Re-Testing Framework

[Jeremy Spewock <jspewock@iol.unh.edu>]

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

Hello all,

I know Aaron and I had talked a little bit about the script for this and
how we were going to handle it during the CI meeting, so I figured I would
raise this on the mailing list so anyone could provide input. One of the
points we had mentioned was whether this was something we wanted to use
pwclient or instead make it a separate script that is just dedicated to
collecting retest requests. I'm not completely sure which one would be the
better option, but as I mentioned during the meeting I did write a little
bit of a draft for a dedicated script that I thought might be something
that would be good to bring up. The below code is just a simple python
script that allows you to pass in the name of contexts you would like to
collect for retesting and it just follows the event schema listed in the
previous email. The thought process with this is every lab could maintain a
list of labels they would like to capture and the timestamp since the last
time they ran the script and gathered retesting requests and use that to
run this script periodically.

There are a couple of things to consider with this script before it is
completely polished like where to send the output and how people want to
handle it, or if we even want to use it rather than just use pwclient and
write something to allow it to handle collecting these requests. I also
wasn't sure if a comma or space separated list would be preferred for
input, so I'm open to suggestions on that as well if we decide to use this
script. I wrote something to handle both comma and space delimiters but it
required flattening the list and a little extra complexity, so I left it
out of the code below. Let me know if anyone has any thoughts on the matter
and how we wanted to handle collecting the requests.

Thanks,
Jeremy

+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2023 University of New Hampshire
+
+import re
+import requests
+import argparse
+class RerunProcessor:
+    """Class for finding reruns inside an email using the patchworks
events API.
+
+    The idea of this class is to use regex to find certain patterns that
represent
+    desired contexts to rerun.
+    """
+    desired_contexts: list[str] = []
+    collection_of_retests: dict = {}
+    #^ is start of line and $ is end
+    # ((?:[a-xA-Z-]+(?:, ?\n?)?)+) is a capture group that gets all test
labels after "Recheck-request: "
+    #   (?:[a-xA-Z-]+(?:, ?\n?)?)+ means 1 or more of the first match group
+    #       [a-xA-Z-]+ means 1 more more of any character in the ranges
a-z or A-Z, or the character '-'
+    #       (?:, ?\n?)? means 1 or none of this match group which expects
exactly 1 comma followed by
+    #                   1 or no spaces followed by 1 or no newlines.
+    # VALID MATCHES:
+    #   Recheck-request: iol-unit-testing, iol-something-else,
iol-one-more, intel-example-testing
+    #   Recheck-request: iol-unit-testing,iol-something-else,iol-one-more,
intel-example-testing,
+    #   Recheck-request: iol-unit-testing, iol-example,
iol-another-example, intel-example-testing,
+    #   more-intel-testing
+    # INVALID MATCHES:
+    #   Recheck-request: iol-unit-testing,
iol-something-else,iol-one-more,  intel-example-testing
+    #   Recheck-request: iol-unit-testing iol-something-else,iol-one-more,
intel-example-testing,
+    #   Recheck-request: iol-unit-testing,iol-something-else,iol-one-more,
intel-example-testing,
+    #
+    #   more-intel-testing
+    regex:str = "^Recheck-request: ((?:[a-xA-Z-]+(?:, ?\n?)?)+)"
+
+    def __init__(self, desired_contexts: list) -> None:
+        self.desired_contexts = desired_contexts
+
+    def process_comment_info(self, list_of_comment_blobs: list[str]) ->
None:
+        """Takes the list of json blobs of comment information and
associates them
+        with their patches.
+
+        Collects retest labels from a list of comments on patches
represented in
+        list_of_comment_blobs and creates a dictionary that associates
them with their
+        corresponding patch series ID. The labels that need to be retested
are collected
+        by passing the comments body into get_test_names() method.
+
+        Args:
+            list_of_comment_blobs: a list of JSON blobs that represent
comment information
+        """
+        for comment in list_of_comment_blobs:
+            comment_info = requests.get(
+                comment["comment"]["url"]
+            )
+            labels_to_rerun =
self.get_test_name(comment_info.json()["content"])
+            patch_id = comment["payload"]["patch"]["id"]
+            #appending to the list if it already exists, or creating it if
it doesn't
+            self.collection_of_retests[patch_id] =
[*self.collection_of_retests.get(patch_id, []), *labels_to_rerun]
+
+    def get_test_names(self, email_body:str) -> list[str]:
+        """Uses the regex in the class to get the information from the
email.
+
+        When it gets the test names from the email, it will all be in one
capture group.
+        We expect a comma separated list of patchwork labels to be
retested.
+
+        Returns:
+            A list of contexts found in the email that match your list of
desired
+            contexts to capture
+        """
+        rerun_section = re.findall(self.regex, email_body, re.MULTILINE)
+        rerun_list = list(map(str.strip, rerun_section[0].split(",")))
+        valid_test_labels = []
+        for test_name in rerun_list:
+            if not test_name: #handle the capturing of empty string
+                continue
+            if test_name in self.desired_contexts:
+                valid_test_labels.append(test_name)
+        return valid_test_labels
+
+
+if __name__ == '__main__':
+    parser = argparse.ArgumentParser(description="Help text for getting
reruns")
+    parser.add_argument('-ts', '--time-since', dest="time_since",
required=True, help="Get all patches since this timestamp")
+    parser.add_argument('--no-cover-comment', dest="no_cover_comment",
default=False, help="Option to ignore comments on cover letters")
+    parser.add_argument('--no-patch-comment', dest="no_patch_comment",
default=False, help="Option to ignore comments on patch emails")
+    parser.add_argument('--contexts', dest="contexts_to_capture",
nargs='*', required=True, help="List of patchwork contexts you would like
to capture")
+    args = parser.parse_args()
+    rerun_processor = RerunProcessor(args.contexts_to_capture)
+    patchwork_url = f"
http://patches.dpdk.org/api/events/?since={args.time_since}"
+    if args.no_cover_comment and args.no_patch_comment:
+        exit(0)
+    if not args.no_cover_comment:
+        patchwork_url += "&category=cover-comment-created"
+    if not args.no_patch_comment:
+        patchwork_url += "&category=patch-comment-created"
+    comment_request_info = requests.get(patchwork_url)
+    rerun_processor.process_comment_info(comment_request_info.json())

On Wed, Jun 21, 2023 at 12:21 PM Ali Alnubani <alialnu@nvidia.com> wrote:

> On 6/6/2023 7:57 PM, Patrick Robb wrote:
> > Hello all,
> >
> > I'd like to revive the conversation about a request from the community
> > for an email based re-testing framework. The idea is that using one
> > standardized format, dpdk developers could email the test-report mailing
> > list, requesting a rerun on their patch series for "X" set of tests at
> > "Y" lab. I think that since patchwork testing labels (ie.
> > iol-broadcom-Performance, github-robot: build, loongarch-compilation)
> > are already visible on patch pages on patchwork, those labels are the
> > most reasonable ones to expect developers to use when requesting a
> > re-test. We probably wouldn't want to get any more general than that,
> > like, say, rerunning all CI testing for a specific patch series at a
> > specific lab, since it would result in a significant amount of "wasted"
> > testing capacity.
> >
> > The standard email format those of us at the Community Lab are thinking
> > of is like below. Developers would request retests by emailing the
> > test-report mailing list with email bodies like:
> >
> > [RETEST UNH-IOL]
> > iol-abi-testing
> > iol-broadcom-Performance
> >
> > [RETEST Intel]
> > intel-Functional
> >
> > [RETEST Loongson]
> > loongarch-compilation
> >
> > [RETEST GHA]
> > github-robot: build
> >
> > From there, it would be up to the various labs to poll the test-report
> > mailing list archive (or use a similar method) to check for such
> > requests, and trigger a CI testing rerun based on the labels provided in
> > the re-test email. If there is interest from other labs, UNH might also
> > be able to host the entire set of re-test requests, allowing other labs
> > to poll a curated list hosted by UNH. One simple approach would be for
> > labs to download all emails sent to test-report and parse with regex to
> > determine the re-test list for their specific lab. But, if anyone has
> > any better ideas for aggregating the emails to be parsed, suggestions
> > are welcome! If this approach sounds reasonable to everyone, we could
> > determine a timeline by which labs would implement the functionality
> > needed to trigger re-tests. Or, we can just add re-testing for various
> > labs if/when they add this functionality - whatever is better. Happy to
> > discuss at the CI meeting on Thursday.
> >
>
> Hello,
>
> For context, and as discussed in the last community CI meeting, going
> through every new patch to look for new comments that trigger retests might
> take too long and potentially slow down the server.
>
> I will upgrade Patchwork to v3.1 right after the v23.07 release.
> The new version adds two new events to the /events API:
> cover-comment-created and patch-comment-created.[1]
>
> An example event schema:
>
> """
> {
>         [..]
>         "category": "patch-comment-created",
>         "project": {
>             [..]
>         },
>         "date": "string",
>         "actor": {
>             [..]
>         },
>         "payload": {
>             "patch": {
>                 [..]
>             },
>             "comment": {
>                 [..]
>                 "url": "https://patches.dpdk.org/api/patches/X/comments/Y/
> ",
>                 [..]
>             }
>         }
>     }
> """
>
> The comments body/contents can be extracted from the "content" property
> after fetching the comment's api url. Example schema:
>
> """
> {
>     [..]
>     "subject": "string",
>     "submitter": {
>         [..]
>     },
>     "content": "string",
>     "headers": {
>         [..]
>     },
>     "addressed": null
> }
> """
>
> [1]
> https://patchwork.readthedocs.io/en/latest/releases/hessian/#relnotes-v3-1-0-stable-3-1-new-features
> Also see:
>
> https://patchwork.readthedocs.io/en/latest/api/rest/schemas/v1.2/#get--api-1.2-events-
>
> https://patchwork.readthedocs.io/en/latest/api/rest/schemas/v1.2/#get--api-1.2-patches-id-comments-
>
> Let me know if you have any questions.
>
> Regards,
> Ali
>

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