Re: CI and test improvements - Mailing list pgsql-hackers

From Andres Freund
Subject Re: CI and test improvements
Date
Msg-id 20221117034814.7m4ucu42e6no3ndq@awork3.anarazel.de
Whole thread Raw
In response to Re: CI and test improvements  (Andres Freund <andres@anarazel.de>)
Responses Re: CI and test improvements
List pgsql-hackers
Hi,

On 2022-10-02 14:54:21 -0700, Andres Freund wrote:
> On 2022-10-02 16:35:06 -0500, Justin Pryzby wrote:
> > On Sun, Oct 02, 2022 at 01:52:01PM -0700, Andres Freund wrote:
> > > On 2022-10-01 18:36:41 -0700, Andres Freund wrote:
> > > > I am wondering if we should instead introduce a new "quickcheck" task that
> > > > just compiles and runs maybe one test and have *all* other tests depend on
> > > > that.  Wasting a precious available windows instance to just fail to build or
> > > > immediately fail during tests doesn't really make sense.
> > 
> > > With a primed cache this takes ~32s, not too bad imo. 12s of that is
> > > cloning the repo.
> > 
> > Maybe - that would avoid waiting 4 minutes for a windows instance to
> > start in the (hopefully atypical) case of a patch that fails in 1-2
> > minutes under linux/freebsd.
> > 
> > If the patch were completely broken, the windows task would take ~4min
> > to start, plus up to ~4min before failing to compile or failing an early
> > test.  6-8 minutes isn't nothing, but doesn't seem worth the added
> > complexity.
> 
> Btw, the motivation to work on this just now was that I'd like to enable more
> sanitizers (undefined,alignment for linux-meson, address for
> linux-autoconf). Yes, we could make the dependency on freebsd instead, but I'd
> like to try to enable the clang-only memory sanitizer there (if it works on
> freebsd)...

I've used this a bunch on personal branches, and I think it's the way to
go. It doesn't take long, saves a lot of cycles when one pushes something
broken. Starts to runs the CompilerWarnings task after a minimal amount of
sanity checking, instead of having to wait for a task running all tests,
without the waste of running it immediately and failing all the different
configurations, which takes forever.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Dmitry Koterov
Date:
Subject: Is the plan for IN(1,2,3) always the same as for =ANY('{1,2,3}') when using PQexec with no params?
Next
From: Tom Lane
Date:
Subject: Re: Is the plan for IN(1,2,3) always the same as for =ANY('{1,2,3}') when using PQexec with no params?