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 341434326F; Thu, 2 Nov 2023 14:03:41 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 19AC540282; Thu, 2 Nov 2023 14:03:41 +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 C3CE840262 for ; Thu, 2 Nov 2023 14:03:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1698930218; 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=RyORhh524Kv126J174sKLHrw0LJ844CUnOGHBDwtG6c=; b=ftcmVk37Xk1fKhrDG9TqVk92jE2FEqAOxdmPh9MG2924cHF+/o2goykSBB9GQbRGXpkJUk BvGmuFBXydbHdmEfDbgY62cuvZ8CqS2TNoIVW4b9G3Z1cAlKxXbM7i/X9GU50CUpu5hOMo tXZsiN4bQLIbr5ooKd79HSH0UCYEquA= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-282-Kfe6A32lNxGvtGqDoF4_Ew-1; Thu, 02 Nov 2023 09:03:36 -0400 X-MC-Unique: Kfe6A32lNxGvtGqDoF4_Ew-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (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 3AE10862CA1; Thu, 2 Nov 2023 13:03:36 +0000 (UTC) Received: from RHTPC1VM0NT (unknown [10.22.9.87]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D26A7492BE0; Thu, 2 Nov 2023 13:03:35 +0000 (UTC) From: Aaron Conole To: Thomas Monjalon Cc: Michael Santana , ci@dpdk.org, Dumitru Ceara , David Marchand , Ilya Maximets Subject: Re: [RFC 2/2] recheck: Add a recheck parser for patchwork comments References: <20231027130609.3035396-1-aconole@redhat.com> <1912626.taCxCBeP46@thomas> Date: Thu, 02 Nov 2023 09:03:35 -0400 In-Reply-To: <1912626.taCxCBeP46@thomas> (Thomas Monjalon's message of "Thu, 02 Nov 2023 11:44:53 +0100") 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.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 Thomas Monjalon writes: > 01/11/2023 20:16, Aaron Conole: >> Michael Santana writes: >> > I like this workflow. The only thing that I do not like is that you >> > have to check every comment on every patch. That seems like an >> > expensive operation, but honestly I do not think there is a better way >> > to accomplish this. So if there is no better way to do it then it's >> > okay, let's move forward with it >> >> There isn't a different way to do it for now, but I hope to switch to >> using the events API which should mean we only look at the most recent >> events that come in. > > What prevent us to use the events API? Ideally we could use it everywhere, but the pw-ci project is used for other patchwork instances. Events API for comments is a recent change, and not every patchwork instance is upgraded to support it (for example, both ozlabs and kernel.org patchwork instances don't have support). I do have some detection code, and am planning on hooking that up so that we can detect whether events API supports comment events based on the filters offered, but that takes some time to test and validate. So it becomes a question of which is more important - having something working now, or spending time with the detection code. Either way, we need it for older patchworks that haven't upgraded to the just released version (some projects are still on 2.2.0). If you think it is better to do the events path first, I can go with that but then we severely limit which projects get support for rechecks, and I've already gotten the feature request for both OVS and OVN - so we'd either need to support comments polling anyway, or do the massive work of upgrading ozlabs instance.