Horton

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

Peter Eisentraut <peter@eisentraut.org>

View thread View on postgr.es
From: Peter Eisentraut <peter@eisentraut.org>
To: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org, Thomas Munro <thomas.munro@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>
Date: 2023-08-08T14:28:49Z
Lists: pgsql-hackers 
On 08.08.23 04:15, Andres Freund wrote:
> Potential paths forward for individual CI:
> 
> - migrate wholesale to another CI provider
> 
> - split CI tasks across different CI providers, rely on github et al
>    displaying the CI status for different platforms
> 
> - give up

With the proposed optimizations, it seems you can still do a fair amount 
of work under the free plan.

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

I think we should use the "compute credits" plan from Cirrus CI.  It 
should be possible to estimate the costs for that.  Money is available, 
I think.

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