Re: Heads Up: cirrus-ci is shutting down June 1st

Hi,

On 2026-06-03 16:03:20 -0700, Jacob Champion wrote:
> On Wed, Jun 3, 2026 at 12:57 PM Andres Freund <andres@anarazel.de> wrote:
> > On 2026-06-03 11:12:43 -0700, Jacob Champion wrote:
> > > Are we certain that GitHub isn't going to opt them all into
> > > test-every-stable-commit-and-PR on their next sync?
> >
> > It'd not test every stable commit, just the ones separately pushed, no?
> 
> Ah. Slightly embarrassing: I misunderstood the Sync Fork functionality
> in GitHub, which I'd never actually used. It's a one-time
> synchronization, not a permanent "keep this up to date" toggle, so the
> situation's not as alarmingly carbon-intensive as I made it sound.
> 
> So yes, just every push. I don't know if the Sync Fork button acts as
> a push trigger as well.

Jacob and I just tested this with a test account that I had around.  A new
fork starts out with disabled workflows. But forking before this and then
resyncing / pulling remaining changes, does lead to the workflow being
disabled.


> > > I guess I'll pipe up again to mention that we have a lot of downstream
> > > forks.
> >
> > I'm not entirely unconcerned, but I think requiring explicit per-repo
> > configuration in a postgres specific way will cause more harm long term
> 
> What kind of harm are we talking about -- just that they have to
> follow the steps that our hypothetical skip logic prints out, or else
> ask on the list?

Yes.  I spent a decent chunk of time helping folks set up CI for
cirrus-ci. And yet there continued to be folks that were surprised you could
run CI for yourself.



> Concretely: I propose that we bail out of the setup step if the
> repository isn't postgres/postgres, just for the initial committed
> version, and then we can test what this actually does in practice to
> our downstream forks. If I'm being overly paranoid, we can immediately
> remove it; else we can add an opt-in. But adding it after the fact
> won't protect anyone who synced up in the interim.

We clearly would need to have an opt-out from that from the get-go, otherwise
I couldn't even test that things are still working before merging, and
postgresql-cfbot won't work...  Thomas has it otherwise mostly ready to go
(this thread actually is being tested automatically already).

Greetings,

Andres Freund