Horton

Re: Cirrus-ci is lowering free CI cycles - what to do with cfbot, etc?

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: pgsql-hackers@postgresql.org, Thomas Munro <thomas.munro@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>
Date: 2023-08-09T01:26:04Z
Lists: pgsql-hackers 
Hi,

On 2023-08-08 11:58:25 +0300, Heikki Linnakangas wrote:
> On 08/08/2023 05:15, Andres Freund wrote:
> > With the improvements detailed below, cirrus' free CI would last
> > about ~65 runs / month.
>
> I think that's plenty.

Not so sure, I would regularly exceed it, I think. But it definitely will
suffice for more casual contributors.


> > Potential paths forward for cfbot, in addition to the above:
> > 
> > - Pay for compute / ask the various cloud providers to grant us compute
> >    credits. At least some of the cloud providers can be used via cirrus-ci.
> > 
> > - Host (some) CI runners ourselves. Particularly with macos and windows, that
> >    could provide significant savings.
> > 
> > - Build our own system, using buildbot, jenkins or whatnot.
> > 
> > 
> > Opinions as to what to do?
> 
> The resources for running our own system isn't free either. I'm sure we can
> get sponsors for the cirrus-ci credits, or use donations.

As outlined in my reply to Alvaro, just using credits likely is financially
not viable...


> > 5) Move use of -Dsegsize_blocks=6 from macos to linux
> > 
> >     Macos is expensive, -Dsegsize_blocks=6 slows things down. Alternatively we
> >     could stop covering both meson and autoconf segsize_blocks. It does affect
> >     runtime on linux as well.
> 
> Could we have a comment somewhere on why we use -Dsegsize_blocks on these
> particular CI runs? It seems pretty random. I guess the idea is to have one
> autoconf task and one meson task with that option, to check that the
> autoconf/meson option works?

Hm, some of that was in the commit message, but I should have added it to
.cirrus.yml as well.

Normally, the "relation segment" code basically has no coverage in our tests,
because we (quite reasonably) don't generate tables large enough. We've had
plenty bugs that we didn't notice due the code not being exercised much. So it
seemed useful to add CI coverage, by making the segments very small.

I chose the tasks by looking at how long they took at the time, I
think. Adding them to to the slower ones.


> > 6) Disable write cache flushes on windows
> > 
> >     It's a bit ugly to do this without using the UI... Shaves off about 30s
> >     from the tests.
> 
> A brief comment would be nice: "We don't care about persistence over hard
> crashes in the CI, so disable write cache flushes to speed it up."

Turns out that patch doesn't work on its own anyway, at least not
reliably... I tested it by interactively logging into a windows vm and testing
it there. It doesn't actually seem to suffice when run in isolation, because
the relevant registry key doesn't yet exist. I haven't yet figured out the
magic incantations for adding the missing "intermediary", but I'm getting
there...

Greetings,

Andres Freund

Commits

  1. Use snprintf instead of sprintf in pg_regress.

  2. Speed up pg_regress server readiness testing.

  3. ci: Make compute resources for CI configurable

  4. ci: Prepare to make compute resources for CI configurable

  5. ci: Use VMs for SanityCheck and CompilerWarnings

  6. ci: Move execution method of tasks into yaml templates

  7. ci: Don't specify amount of memory

  8. ci: macos: Remove use of -Dsegsize_blocks=6

  9. ci: macos: Remove use of -DRANDOMIZE_ALLOCATED_MEMORY