MIME-Version: 1.0
References: <3ydjipcr7kbss57nvi67noplncqhesl5eyb6wgol4ccjxynspv@yatlykpribmm>
In-Reply-To: <3ydjipcr7kbss57nvi67noplncqhesl5eyb6wgol4ccjxynspv@yatlykpribmm>
From: Jelte Fennema-Nio <postgres@jeltef.nl>
Date: Fri, 10 Apr 2026 13:31:38 +0200
Message-ID: 
 <CAGECzQSBkeZHT+mgshM7bHXvVUctQyMcG9vdbATHE_pNfHz2MA@mail.gmail.com>
Subject: Re: Heads Up: cirrus-ci is shutting down June 1st
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAGECzQSBkeZHT%2BmgshM7bHXvVUctQyMcG9vdbATHE_pNfHz2MA%40mail.gmail.com>
Precedence: bulk

On Thu, 9 Apr 2026 at 22:55, Andres Freund <andres@anarazel.de> wrote:
> I'd be interested in feedback about how high folks value different aspects:

My thoughts below.

> 1) CI software can be self hosted
>
>    E.g. to prevent at least the cfbot case from being unpredictably abandoned
>    again.

Low, I personally don't want to manage self hosting it. Self-hosted
software can just as easily be abandoned. i.e. I'd expect GitHub
Actions to outlive underfunded open source CI software.

> 2) CI software is open source
>
>    E.g. out of a principled stance, or control concerns.

I don't care

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

Important. We should definitely be able to pre-install stuff for most
OSes. I think running stuff in containers would be fine.

> 4) CI tests as many operating systems as possible

I think we at minimum need linux+macos+windows. Windows is by far the
system that fails most often for me. BSDs would be good, but they
often tend to be fine if osx and linux work. Personally for me I think
on Cirrus The BSDs didn't meet the useful signal to flakiness noise
ratio (i.e. they tended to mostly break randomly for me).

> 5) CI can be enabled on one's own repositories
> ...
> 6) There need to be free credits for running at least some CI on one's own
>    repository
> ...
> 7) Provide CI compute for "well known contributors" for free in their own
>    repositories

I would say it's a hard requirement that people can run CI without
spamming the list. I don't think that necessarily has to be in
someone's own repository. e.g. having a way for committers to give
e.g. some limited number (e.g. 100) of CI hours to someone submitting
their first patch seems fairly low risk. If they continue contributing
they can receive a recurring number or unlimited access.

On Thu, 9 Apr 2026 at 22:55, Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> 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.
>
>
> 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.
>
>
> For some context about how much CI we have been running, here's the daily
> average for cfbot and postgres/postgres CI:
>
> - 1464 core hours (full cores, not SMT), all CI jobs use 4 cores
>
> - 396 core hours of which were windows (visible due to the licensing cost)
>
> - 40 GB of artifacts
>
> - 83 GB of artifacts downloaded externally
>
> - doesn't include macos, which I can't track as easily, due to being self
>   hosted runners, rather than running on GCP, which provided the above numbers
>
>
> Greetings,
>
> Andres Freund
>
>