From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 75C34A00C2 for ; Tue, 25 Jan 2022 14:05:37 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 04298429D4; Tue, 25 Jan 2022 14:05:36 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id E16DC429BF for ; Tue, 25 Jan 2022 14:05:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1643115934; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=llzA0bXr6YzbD67aiaE02sbKLOFhFGqBOq76w0iLntI=; b=F6sybOjp3CX97EE5ewWxr+GZ3OCaNXVGPqUcd3PYNR6wFCZohtkvA6OyCMfdHMF3fvbXLO 1pipgE5A/zqb6isSufxoPABZEy451idn0/4lR5bYSqLws5wBiqxHbCmu7GsZuqymDXK1v/ YryGLztnJQsnIWqTB6Ykb8bOcza8AQQ= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-670-788FJWITMWq4tNQ502sHig-1; Tue, 25 Jan 2022 08:05:26 -0500 X-MC-Unique: 788FJWITMWq4tNQ502sHig-1 Received: by mail-wm1-f72.google.com with SMTP id j18-20020a05600c1c1200b0034aeea95dacso1177770wms.8 for ; Tue, 25 Jan 2022 05:05:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:subject:in-reply-to :content-transfer-encoding; bh=llzA0bXr6YzbD67aiaE02sbKLOFhFGqBOq76w0iLntI=; b=g5yeSQihxJ3LquZQ1Nchr7ywbwhI6n20iYlhTqyFs0c2UYOCVYOCDRaTX5xv+Kproh 19XGQ9mz4mIn/fH8svw3AGbqRajw/Rjdb7nqDP0L+jYHshXB6iUzoAwtZDXty0LJGrpL 9Ytwe0PgqQzE2+EhV/wKng/04GOQlA+jsr0hHvn2HNpcadC4yirlJbq0aY7MEC/pXyk+ NAz1ijPWi4f/V/W5DjCxVwR5EIwtxp1FnHWG/+aDnxdMA+6W0s6FYkxWrurMaxy4tsY/ 1YOri/V4fyQdQqkv3ERFbBrnyfCt/+6+PBKJADqftSA5536jejGEHKgnjWDXTVR1rCG+ 5O4Q== X-Gm-Message-State: AOAM530KkY3SBxeC6cluCdyKma0KkV4ejUJhG+/u2eCDfp17UsHrCd9y LSEo92aOVcUdOKqOODph+fI30iCb6dFUmWLRbSqd29pKVN8lqHknVqSkyp5uLoJBI0nxcH1Tqvr H1w== X-Received: by 2002:a05:6000:1869:: with SMTP id d9mr8472508wri.432.1643115924938; Tue, 25 Jan 2022 05:05:24 -0800 (PST) X-Google-Smtp-Source: ABdhPJzPi6Zn5gyJR6WTcyID03VFON6CgGI7k6m1sdHx8YHC1XJrj2MtXpGKT7G4Z74a5M6/FLp3aQ== X-Received: by 2002:a05:6000:1869:: with SMTP id d9mr8472487wri.432.1643115924704; Tue, 25 Jan 2022 05:05:24 -0800 (PST) Received: from [192.168.0.36] ([78.19.108.41]) by smtp.gmail.com with ESMTPSA id p26sm360634wms.2.2022.01.25.05.05.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Jan 2022 05:05:24 -0800 (PST) Message-ID: <5d231097-cc57-a794-f57d-67c6c138e15c@redhat.com> Date: Tue, 25 Jan 2022 13:05:22 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 To: Lincoln Lavoie Cc: Aaron Conole , dev , ci@dpdk.org, Michael Santana , dpdklab References: From: Kevin Traynor Subject: Re: [dpdklab] Re: [dpdk-ci] [RFC] Proposal for allowing rerun of tests In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=ktraynor@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ci@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK CI discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ci-bounces@dpdk.org On 21/01/2022 17:57, Lincoln Lavoie wrote: > Hi Kevin, > Hi Lincoln, > I'll add some notes around this to the 2022 planning doc. The retests > requests for the periodic tests are tricky from the discussed patchworks / > mailing list approach, because there isn't an associated patch or patch > ID. So, we just need to document or agree on how to "flag" what the > request is, so the system could uniquely ID what branch / test to rerun. > > I'll also add this to the list for the dashboard technical debt as well, as > there may be a graphical interface stuff (i.e. a button) we could add to > the UNH-IOL hosted testing. > From my point of view, I don't really mind how a re-test is triggered. I was just suggesting a "button" as a way of saying that we mightn't need the complexity of parsing emails etc. as there would be just a few branch maintainers and a few requests. But if it's more complex updating the dashboard, then that might not be best solution. As always, please consider this just one request. If others don't see relative value in it, then makes sense to drop it or select something more important ahead of it. thanks, Kevin. > Cheers, > Lincoln > > On Fri, Jan 21, 2022 at 9:00 AM Kevin Traynor wrote: > >> On 13/04/2021 14:50, Aaron Conole wrote: >>> Greetings, >>> >>> During the various CI pipelines, sometimes a test setup or lab will >>> have an internal failure unrelated to the specific patch. Perhaps >>> 'master' branch (or the associated -next branch) is broken and we cannot >>> get a successful run anyway. Perhaps a network outage occurs during >>> infrastructure setup. Perhaps some other transient error clobbers the >>> setup. In all of these cases the report to the mailing flags the patch >>> as 'FAIL'. >>> >>> It would be very helpful if maintainers had the ability to tell various >>> CI infrastructures to restart / rerun patch tests. For now, this has to >>> be done by the individual managers of those labs. Some labs, it isn't >>> possible. Others, it's possible but is a very time-consuming process to >>> restart a test case. In all cases, a maintainer needs to spend time >>> communicating with a lab manager. This could be made a bit nicer. >>> >> >> Just to tie two relevant threads together. I made a request in >> http://mails.dpdk.org/archives/ci/2022-January/001593.html for a >> "retest" button (or really any manual but self-sufficient way) to >> kick-off immediately what is run in periodic branch testing. Something >> might be there already, that i'm just not aware of. >> >> This could be used by LTS maintainers, and possibly main, *-next branch >> maintainers coming up to releases. >> >> thanks, >> Kevin. >> >>> One proposal we (Michael and I) have toyed with for our lab is having >>> the infrastructure monitor patchwork comments for a restart flag, and >>> kick off based on that information. Patchwork tracks all of the >>> comments for each patch / series so we could look at the series that >>> are still in a state for 'merging' (new, assigned, etc) and check the >>> patch .comments API for new comments. Getting the data from PW should >>> be pretty simple - but I think that knowing whether to kick off the >>> test might be more difficult. We have concerns about which messages we >>> should accept (for example, can anyone ask for a series to be rerun, and >>> we'll need to track which rerun messages we've accepted). The >>> convention needs to be something we all can work with (ie: /Re-check: >>> [checkname] or something as a single line in the email). >>> >>> This is just a start to identify and explain the concern. Maybe there >>> are other issues we've not considered, or maybe folks think this is a >>> terrible idea not worth spending any time developing. I think there's >>> enough use for it that I am raising it here, and we can discuss it. >>> >>> Thanks, >>> -Aaron >>> >> >> >