Re: Heads Up: cirrus-ci is shutting down June 1st - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Heads Up: cirrus-ci is shutting down June 1st
Date
Msg-id eadb78b2-0aa1-4975-9819-0ebebe2f983b@iki.fi
Whole thread Raw
In response to Heads Up: cirrus-ci is shutting down June 1st  (Andres Freund <andres@anarazel.de>)
Responses Re: Heads Up: cirrus-ci is shutting down June 1st
List pgsql-hackers
On 09/04/2026 23:55, Andres Freund wrote:
> As the subject says, cirrus-ci, which cfbot uses to run CI and that one can
> (for now) enable on one's own repository, is shutting down.
> 
> https://cirruslabs.org/ burries the lede a bit, but it has further down:
>    "Cirrus CI will shut down effective Monday, June 1, 2026."
> 
> I can't say I'm terribly surprised, they had been moving a lot slower in the
> last few years.

Darn, I liked Cirrus CI. One reason being precisely that it has been 
stable, i.e. moved slowly, for years :-).

> I think having cfbot and CI that one could run on ones own repository, without
> sending a mail to the community, has improved the development process a lot.
> So clearly we're going to have to do something.  I certainly could not have
> done stuff like AIO without it.

+1. I rely heavily on cirrus CI nowadays to validate before I push.

> I'd be interested in feedback about how high folks value different aspects:
> 
> 1) CI software can be self hosted
> 
>     E.g. to prevent at least the cfbot case from being unpredictably abandoned
>     again.
> 
> 
> 2) CI software is open source
> 
>     E.g. out of a principled stance, or control concerns.

These probably go together.

I think it's important that you can self-host. Even with cirrus-ci I 
actually wished there was an easy way to run the jobs locally. I don't 
know how often I'd really do it, but especially developing and testing 
the ci yaml files is painful when you can't run it locally.

> 3) CI runs quickly
> 
>     This matters e.g. for accepting running in containers and whether it's
>     crucial to be able to have our images with everything pre-installed.

Pretty important. "quickly" is pretty subjective though, I'm not sure 
what number to put to it. Cirrus-CI has felt fast enough.

> 4) CI tests as many operating systems as possible
> 
>     A lot of system just support linux, plenty support macos, some support
>     windows. Barely any support anything beyond that.

Windows support is pretty important as it's different enough from 
others. Macos is definitely good to have too. For others, we have the 
buildfarm.

> 5) CI can be enabled on one's own repositories
> 
>     Cfbot obviously allows everyone to test patches some way, but sending patch
>     sets to the list just to get a CI run obviously gets noisy quite fast.
> 
>     There are plenty of open source CI solutions, but clearly it's not viable
>     for everyone to set that up for themselves. Plenty providers do allow doing
>     so, but the overlap of this, open source (2), multiple platforms (4) is
>     small if it exists.

This is important. I run the CI as part of development on my own 
branches all the time.

If it's easy to self-host, that might cover it.

> 6) There need to be free credits for running at least some CI on one's own
>     repository
> 
>     This makes the overlapping constraints mentioned in 5) even smaller.
> 
>     There are several platforms that do provide a decent amount of CI for a
>     monthly charge of < 10 USD.

Not important. For running on one's own repository, it's totally 
reasonable that you pay for it yourself. Especially if you can self-host 
for free.

> 7) Provide CI compute for "well known contributors" for free in their own
>     repositories
> 
>     An alternative to 6) - with some CI solutions - can be to add folks to some
>     team that allows them to use community resources (which so far have been
>     donated).  The problem with that is that it's administratively annoying,
>     because one does need to be careful, or CI will be used to do
>     cryptocurrency mining or such within a few days.

Not important. Active contributors can easily pay for what they use, or 
self-host.

- Heikki



pgsql-hackers by date:

Previous
From: Andrew Kim
Date:
Subject: Re: Proposal for enabling auto-vectorization for checksum calculations
Next
From: SATYANARAYANA NARLAPURAM
Date:
Subject: Re: Bug: Rule actions see wrong values for generated columns (NEW.gen reads OLD value)