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)
