Re: CI and test improvements - Mailing list pgsql-hackers
From | Justin Pryzby |
---|---|
Subject | Re: CI and test improvements |
Date | |
Msg-id | 20221002005801.GB7745@telsasoft.com 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 |
On Sat, Oct 01, 2022 at 05:45:01PM -0700, Andres Freund wrote: > Hi, > > On 2022-09-10 15:05:42 -0500, Justin Pryzby wrote: > > From 4ed5eb427de4508a4c3422e60891b45c8512814a Mon Sep 17 00:00:00 2001 > > From: Justin Pryzby <pryzbyj@telsasoft.com> > > Date: Sun, 3 Apr 2022 00:10:20 -0500 > > Subject: [PATCH 03/23] cirrus/ccache: disable compression and show stats > > > > Since v4.0, ccache enables zstd compression by default, saving roughly > > 2x-3x. But, cirrus caches are compressed as tar.gz, so we could disable > > ccache compression, allowing cirrus to gzip the uncompressed data > > (better than ccache's default of zstd-1). > > I wonder whether we could instead change CCACHE_COMPRESSLEVEL (maybe 3, zstd's > default IIRC). It'd be good if we could increase cache utilization. I considered that (and I think that's what I wrote initially). I figured that if cirrus is going to use gzip-6 (tar.gz) in any case, we might as well disable compression. Then, all the tasks are also doing the same thing (half the tasks have ccache before 4.0). > > From 0bd5f51b8c143ed87a867987309d66b8554b1fd6 Mon Sep 17 00:00:00 2001 > > From: Justin Pryzby <pryzbyj@telsasoft.com> > > Date: Thu, 14 Apr 2022 06:27:07 -0500 > > Subject: [PATCH 05/23] cirrus: enable various runtime checks on macos and > > freebsd > > > > windows is slower than freebsd and mac, so it's okay to enable options which > > will slow them down some. Also, the cirrusci mac instances always have lot of > > cores available. > > > See: > > https://www.postgresql.org/message-id/20211217193159.pwrelhiyx7kevgsn@alap3.anarazel.de > > https://www.postgresql.org/message-id/20211213211223.vkgg3wwiss2tragj%40alap3.anarazel.de > > https://www.postgresql.org/message-id/CAH2-WzmevBhKNEtqX3N-Tkb0gVBHH62C0KfeTxXzqYES_PiFiA%40mail.gmail.com > > https://www.postgresql.org/message-id/20220325000933.vgazz7pjk2ytj65d@alap3.anarazel.de > > > > ci-os-only: freebsd, macos > > --- > > .cirrus.yml | 8 +++++--- > > 1 file changed, 5 insertions(+), 3 deletions(-) > > > > diff --git a/.cirrus.yml b/.cirrus.yml > > index 183e8746ce6..4ad20892eeb 100644 > > --- a/.cirrus.yml > > +++ b/.cirrus.yml > > @@ -113,7 +113,9 @@ task: > > \ > > CC="ccache cc" \ > > CXX="ccache c++" \ > > - CFLAGS="-Og -ggdb" > > + CPPFLAGS="-DRELCACHE_FORCE_RELEASE -DCOPY_PARSE_PLAN_TREES -DWRITE_READ_PARSE_PLAN_TREES -DRAW_EXPRESSION_COVERAGE_TEST"\ > > + CXXFLAGS="-Og -ggdb -march=native -mtune=native" \ > > + CFLAGS="-Og -ggdb -march=native -mtune=native" > > What's reason for -march=native -mtune=native here? No particular reason, and my initial patch didn't have it. I suppose I added it to test its effect and never got rid of it. > > EOF > > build_script: | > > su postgres -c "ccache --zero-stats" > > @@ -336,8 +338,8 @@ task: > > CC="ccache cc" \ > > CXX="ccache c++" \ > > CLANG="ccache ${brewpath}/llvm/bin/ccache" \ > > - CFLAGS="-Og -ggdb" \ > > - CXXFLAGS="-Og -ggdb" \ > > + CFLAGS="-Og -ggdb -DRANDOMIZE_ALLOCATED_MEMORY" \ > > + CXXFLAGS="-Og -ggdb -DRANDOMIZE_ALLOCATED_MEMORY" \ > > \ > > LLVM_CONFIG=${brewpath}/llvm/bin/llvm-config \ > > PYTHON=python3 > > I'd also use CPPFLAGS here, given you'd used it above... > > I'm planning to commit an updated version of this change soon, without the > -march=native -mtune=native bit, unless somebody protests... One other thing is that your -m32 changes caused the linux/meson task to take an additional 3+ minutes (total ~8). That's no issue, except that the Warnings task depends on the linux/mason task, and itself can take up to 15 minutes. So those two potentially take as long as the windows task. I suggested that CompileWarnings could instead "Depend on: Freebsd", which currently takes 6-7min (and could take 4-5min if given more CPUs). -- Justin
pgsql-hackers by date: