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