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

On Fri, Apr 10, 2026 at 3:23 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> On Thu, Apr 9, 2026 at 11:55 PM Andres Freund <andres@anarazel.de> 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.
> >
> > The shutdown window is pretty short, so we'll have to do something soon. Glad
> > that it didn't happen a few months ago, putting the shutdown before the
> > feature freeze. This is probably close to the least bad time it could happen
> > with a short window.
>
>
> +1
>
> >
> > 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.
> >
> >
> > 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.
> >
> >
> > 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.
> >
> >
> > 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.
> >
> >
> > 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.
> >
> >
> > 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.
> >
> >
> > 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.
>
> It's hard for me to judge priorities, but I have a proposal on how we
> can try to handle this.
>
> Migrate to Open Source CI software, and run it on (cheap) cloud + get
> sponsorship to cover the migration cost.

Sorry, I meant sponsorship to cover the cloud cost.

------
Regards,
Alexander Korotkov
Supabase