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: