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 1n9YQU-0002Py-A6 for pgsql-hackers@arkaria.postgresql.org; Mon, 17 Jan 2022 20:16:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n9YQT-0007j8-6k for pgsql-hackers@arkaria.postgresql.org; Mon, 17 Jan 2022 20:16:25 +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 1n9YQS-0007iz-Td for pgsql-hackers@lists.postgresql.org; Mon, 17 Jan 2022 20:16:24 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n9YQQ-0006cn-Cp for pgsql-hackers@postgresql.org; Mon, 17 Jan 2022 20:16:24 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 456C95C003B; Mon, 17 Jan 2022 15:16:21 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 17 Jan 2022 15:16:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=B92dBLd9a3Go4ncCsBaJ10yfc7U qqCix3XZhSvCndiM=; b=NT4EfFRJF0z7d/h2NGC1cUjLbeZBYj0ovUWgnwUaWaA I759W1x0nn5zxeVp+/bEexrwoSeOTQYSbZvVxuIwjsZ2TUE4yTOrcxYxO/a5WCIs 3CPEYxcuDj171KHFl5yJY2+IHZoIdkcnR4xtjw0JldjqipS/FHiwIAmZEKKtud0q gQjLlCom59oJicjSp7wWOFFlA5+ksig/aa2dvCxqCFWgK6+S7wI8Ei4DCn9Cutki 8JnkAUMpkgTURKW6RYSqwBLHoQpBk5oZjDOpg2sMN42QtfocGH+Mu7ZJXB46J8QL zFy+esSuu/Y+tDMUlN//F8kPWG7xyh9ylCawoGqf1Qw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=B92dBL d9a3Go4ncCsBaJ10yfc7UqqCix3XZhSvCndiM=; b=gnXopllNNbRKGeOUE9KkUO uwggAEdvFJze/o3DtiE0GnBJ4vNVecK9nSmAm9uwlhr0jQ/Nc/PiSKJOd+oP5sjV fPrgClxL1euPnfgzsFBMEkWwp1JiPlMKMphFfbWFwgJJ6TlrjxevQKLaRal1dIBu kXusfvyh5XFrf9X5gyUXCWJfZXEEJjGsWNMCyJUHLtrQsi7aDxswz3vdqdpcnFFs CTdlyKUueuR5NmZzsoaIGaqlUB6ekLMeJ4E79MfFSwSGvwG02zrdJTqoAMTgZuws NCxj0lru7xLRNgmK0Y0mpmNy9iH1I5G0ZhwXR3jmmmNzbMvR4mcaXFBnYQD01oJg == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddruddugddufeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeetnhgurhgv shcuhfhrvghunhguuceorghnughrvghssegrnhgrrhgriigvlhdruggvqeenucggtffrrg htthgvrhhnpeevhfejveehvddvgfdtueefuefhhfetkefgfedtkefhieeuudefveduffdu gfdvgeenucffohhmrghinheptghirhhruhhsqdgtihdrtghomhenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrnhgurhgvshesrghnrghrrgii vghlrdguvg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 17 Jan 2022 15:16:20 -0500 (EST) Date: Mon, 17 Jan 2022 12:16:19 -0800 From: Andres Freund To: Tom Lane Cc: Robert Haas , Andrew Dunstan , Justin Pryzby , "pgsql-hackers@postgresql.org" , Thomas Munro , Melanie Plageman , Peter Eisentraut , Daniel Gustafsson Subject: Re: Adding CI to our tree Message-ID: <20220117201619.3ltudwhgk2krmoki@alap3.anarazel.de> References: <20220110220748.GS14051@telsasoft.com> <20220113185527.kgzmxutkydkyktuq@alap3.anarazel.de> <63f3be31-d7c4-0ff4-e5f4-7368863da1bc@dunslane.net> <20220114233411.2byuid4umwjqbhug@alap3.anarazel.de> <20220114235457.GQ14051@telsasoft.com> <87a81b91-87bf-c0bc-7e4f-06dffadcf737@dunslane.net> <20220117181946.bmvubqpzqxlvmgeh@alap3.anarazel.de> <20220117192510.txue5mihjaxlngep@alap3.anarazel.de> <85428.1642447853@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85428.1642447853@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 2022-01-17 14:30:53 -0500, Tom Lane wrote: > Andres Freund writes: > > I think it's not actually that hard, with something like I described in the > > email upthread, with each tests going into a prescribed location, and the > > on-disk status being inspectable in an automated way. check-world could invoke > > a command to summarize the tests at the end in a .NOTPARALLEL, to make the > > local case easier. > > That sounds a bit, um, make-centric. At this point it seems to me > we ought to be thinking about how it'd work under meson. Some of this is a lot easier with meson. It has a builtin test runner, which understands tap (thereby not requiring prove anymore). Those tests can be listed (meson test --list). Depending on the option this results in a list of all tests with just the "topline" name of passing tests and error output from failing tests, or all output all the time or ... At the end it prints a summary of test counts and a list of failed tests. Here's an example (the leading timestamps are from CI, not meson), on windows: https://api.cirrus-ci.com/v1/task/6009638771490816/logs/check.log The test naming isn't necessarily great, but that's my fault. Running all the tests with meson takes a good bit less time than running most, but far from all, tests using vcregress.pl: https://cirrus-ci.com/build/4611852939296768 meson test makes it far easier to spot which tests failed, it's consistent across operating systems, allows to skip individual tests, etc. However: It doesn't address the log collection issue in itself. For that we'd still need to collect them in a way that's easier to associate with individual tests. In the meson branch I made it so that each test (including individual tap ones) has it's own log directory, which makes it easier to select all the logs for a failing test etc. > > This subthread is about the windows tests specifically, where it's even worse > > - there's no way to run all tests. > > That's precisely because the windows build doesn't use make. > We shouldn't be thinking about inventing two separate dead-end > solutions to this problem. Agreed. I think some improvements, e.g. around making the logs easier to associate with an individual test, is orthogonal to the buildsystem issue. I think it might still be worth adding stopgap way of running all tap tests on windows though. Having a vcregress.pl function to find all directories with t/ and run the tests there, shouldn't be a lot of code... Greetings, Andres Freund