Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n582y-0006VC-K3 for pgsql-www@arkaria.postgresql.org; Wed, 05 Jan 2022 15:17:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n582x-0003Bd-2c for pgsql-www@arkaria.postgresql.org; Wed, 05 Jan 2022 15:17:51 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n582w-0003BU-Ry for pgsql-www@lists.postgresql.org; Wed, 05 Jan 2022 15:17:50 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n582s-0001rb-Ip for pgsql-www@lists.postgresql.org; Wed, 05 Jan 2022 15:17:50 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 205FHf6i043300; Wed, 5 Jan 2022 10:17:41 -0500 From: Tom Lane To: Dave Page cc: Andres Freund , pgsql-www@lists.postgresql.org Subject: Re: Enable CI on postgres/postgres github repo? In-reply-to: References: <20220104235112.bnx6pczz7h3jbu2o@alap3.anarazel.de> Comments: In-reply-to Dave Page message dated "Wed, 05 Jan 2022 09:15:45 +0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <43298.1641395861.1@sss.pgh.pa.us> Date: Wed, 05 Jan 2022 10:17:41 -0500 Message-ID: <43299.1641395861@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Dave Page writes: > On Tue, Jan 4, 2022 at 11:51 PM Andres Freund wrote: >> Now that the CI patch has been merged [1], perhaps it'd make sense to >> enable >> that on the postgres/postgres mirror on github? See [2] for instructions. > Seems reasonable to me - no cost, and very little effort. I'm happy to set > it up if noone objects. I'm kind of down on this actually. Either it will be a waste of cycles because no one looks at the reports, or PG hackers will have to learn to read and interpret a second source of build failure reports. We have a lot of accumulated knowledge about the buildfarm, plus ways to examine past failures, none of which would exist here as far as I've gathered from experience with the cfbot. (And the cfbot's reports definitely suck in usability compared to the farm --- failures often omit critical logs, and what there is is crammed into a single badly-formatted web page.) I guess the bottom line for me is "set it up if you want, but don't expect me to pay any attention to it". regards, tom lane