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)