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

From Jacob Champion
Subject Re: Heads Up: cirrus-ci is shutting down June 1st
Date
Msg-id CAOYmi+mpks_rE5E8fLzANbmhEySK=XC8rAtxi_qPVQKiu6nUGA@mail.gmail.com
Whole thread
In response to Re: 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 Thu, May 28, 2026 at 8:07 AM Andres Freund <andres@anarazel.de> wrote:
> On 2026-05-27 15:15:46 -0700, Jacob Champion wrote:
> > - Do we need to defend our downstream forks from this workflow? (We
> > have 5,700 of them, apparently.)
>
> I don't see why. I think it's good if they run CI. Having forks not run CI by
> default would imo take one of the main advantages of using github actions
> away.

I was imagining a quick opt-in, like the Cirrus flow did, that fork
owners can do once they have checked their settings.

(I thought we planned to research medium-term alternatives to Actions
anyway; is it important that the entire graph starts running hundreds
or thousands of CI copies right away?)

> Yes, they are too permissive by default, including on postgres/postgres.  I
> think postgres/postgres isn't *that* threatened, but we should make things are
> shored up anyway. Where it's really crucial is the postgresql-cfbot repo.

Combining with the above: I'm worried that if all of our 5.7k forks
have permissive settings, and we accidentally ship a workflow
vulnerability that doesn't affect us but does affect them, that would
not be a fun cleanup.

--Jacob



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: future of PQfn()
Next
From: Denis Rodionov
Date:
Subject: [PATCH] Remove obsolete tupDesc assignment in extended statistics