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 0662643B58; Tue, 20 Feb 2024 19:12:38 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4FF9C4067C; Tue, 20 Feb 2024 19:12:37 +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 0D722402A7 for ; Tue, 20 Feb 2024 19:12:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1708452755; 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: in-reply-to:in-reply-to:references:references; bh=7IjMMYlmT22lrOkKoI7doRhS9dUFtWjzcVnrbaTE8GY=; b=K1DGOYqhpInXUoC8rSMYWjv0y/EmzQTghBwPFNzr30t0SqJtCV4eRFfh5ZyE8Zzvuw7qNy i0q7UrB69bX0hMQz/Yx+zgeX6BevIbWTEK/yP660TVRhEo9CySlXX0Qnxo1FgWZsOXR+hs qg89IPFsCCPr5I8/CJUtDhUCII+O6qk= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-574-635shYvoNoCbxuW6dmHdGg-1; Tue, 20 Feb 2024 13:12:30 -0500 X-MC-Unique: 635shYvoNoCbxuW6dmHdGg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D8E683C13A8C; Tue, 20 Feb 2024 18:12:29 +0000 (UTC) Received: from RHTPC1VM0NT (dhcp-17-72.bos.redhat.com [10.18.17.72]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B1CABC01644; Tue, 20 Feb 2024 18:12:29 +0000 (UTC) From: Aaron Conole To: Patrick Robb Cc: ci@dpdk.org, dev@dpdk.org, zhoumin Subject: Re: Email based retest request process: proposal for new pull/re-apply feature References: Date: Tue, 20 Feb 2024 13:12:29 -0500 In-Reply-To: (Patrick Robb's message of "Tue, 20 Feb 2024 10:21:23 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Patrick Robb writes: > 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. Why not something like: Recheck-request: [attribute-list],[test-list]... For example, then we can do: Recheck-request: rebase=[identifier],.... where identifier is a branch specifier (or the word 'latest')? That lets us fixup if the branch picker script guessed a wrong branch. Just spit-balling on syntax. That said, I agree - if a rebase has been requested, all tests need to be rerun. Maybe we should consider that the test labels should be added with a run number or something? Or we could also include that the run is a rerun. That way for labs that don't currently support the recheck request framework, we can easily tell that they weren't re-tried.