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

On 08/08/2023 05:15, Andres Freund wrote:
> IMO, for the individual user case it's important to use CI for "free", without
> a whole lot of complexity. Which imo rules approaches like providing
> $cloud_provider compute accounts, that's too much setup work.

+1

> With the improvements detailed below, cirrus' free CI would last
> about ~65 runs / month.
I think that's plenty.

> For cfbot I hope we can find funding to pay for compute to use for CI.

+1

> 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.

I have been quite happy with Cirrus CI overall.

> The attached series of patches:

All of this makes sense to me, although I don't use macos myself.

> 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?

> 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."

-- 
Heikki Linnakangas
Neon (https://neon.tech)