Re: Cirrus-ci is lowering free CI cycles - what to do with cfbot, etc?
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org,
Thomas Munro <thomas.munro@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>
Date: 2023-08-08T08:58:25Z
Lists: pgsql-hackers
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)
Commits
-
Use snprintf instead of sprintf in pg_regress.
- 8f0fd47fa337 17.0 landed
-
Speed up pg_regress server readiness testing.
- 66d6086cbcbf 17.0 landed
-
ci: Make compute resources for CI configurable
- e4693c68a497 15.5 landed
- e8a8cd05d4b9 16.0 landed
- a28166df8c5a 17.0 landed
-
ci: Prepare to make compute resources for CI configurable
- 284465e1b95e 15.5 landed
- 9ed46c78a362 16.0 landed
- 19cc96503d23 17.0 landed
-
ci: Use VMs for SanityCheck and CompilerWarnings
- 4fdfd0629d77 15.5 landed
- f518c909ead1 16.0 landed
- b2c91d841f1f 17.0 landed
-
ci: Move execution method of tasks into yaml templates
- 462f4df0a86d 15.5 landed
- cad461b044b5 16.0 landed
- 119ee6ab1b00 17.0 landed
-
ci: Don't specify amount of memory
- 89daa5ae307a 15.5 landed
- 5581a9a39530 16.0 landed
- 794e14e219c7 17.0 landed
-
ci: macos: Remove use of -Dsegsize_blocks=6
- 2243ef8dd6fb 16.0 landed
- 3d8d217450a6 17.0 landed
-
ci: macos: Remove use of -DRANDOMIZE_ALLOCATED_MEMORY
- 4bec616f26f5 16.0 landed
- 17ebbdf7de19 17.0 landed