Feedback-ID: id4a34324:Fastmail
Date: Thu, 28 May 2026 12:13:07 -0400
From: Andres Freund <andres@anarazel.de>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Nazir Bilal Yavuz <byavuz81@gmail.com>,
	Jelte Fennema-Nio <postgres@jeltef.nl>,
 Thomas Munro <thomas.munro@gmail.com>,
	pgsql-hackers@postgresql.org
Subject: Re: Heads Up: cirrus-ci is shutting down June 1st
Message-ID: <stjxvg6ghjbfceuhg4gzbmko6sbifbgrpya554jndrclijn56c@hvmzksnfuqf3>
References: <3ydjipcr7kbss57nvi67noplncqhesl5eyb6wgol4ccjxynspv@yatlykpribmm>
 <DIM49A100EY1.2YFS2A6WAI3ZJ@jeltef.nl>
 <CAN55FZ30Np67cATsqYxF1SsP598VoRv4hJQZ4w9RA3Qe55prnQ@mail.gmail.com>
 <CAN55FZ13uX0cLSbgtSnnFeh5sTLeMr7+8UzmqpU6QjOtrRJTLg@mail.gmail.com>
 <qe4lh2i5di2gh7bxkbfisifaohrvyfukbybwxwzxdnll45hnt3@luod7i2mon67>
 <CAOYmi+n8RRmtGUr_fZkYzX5XbGH5+Q0c1M1XMr7ytXbRs1JxJA@mail.gmail.com>
 <qs2jmmyqlmvvj5jfhrkdo5q5fzfjulgiu3dqmgz4gvfscqi4vc@r5rvsrblxres>
 <CAOYmi+mpks_rE5E8fLzANbmhEySK=XC8rAtxi_qPVQKiu6nUGA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAOYmi+mpks_rE5E8fLzANbmhEySK=XC8rAtxi_qPVQKiu6nUGA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/stjxvg6ghjbfceuhg4gzbmko6sbifbgrpya554jndrclijn56c%40hvmzksnfuqf3>
Precedence: bulk

Hi,

On 2026-05-28 08:51:09 -0700, Jacob Champion wrote:
> 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'm not aware of a good way to do that.  I'm sure we could hack up a way,
e.g. by requiring an environment variable to be configured on the repo level
to opt-in, but it seems pretty crufty.

I think making it easier for forks to run CI is a far bigger gain than the
risk of GHA doing something stupid in a fork.  There were a lot of folks that
didn't realize that they could run CI individually or had a hard time enabling
it.


> (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?)

I suspect where we will end up coming out is that we use an alternative for
actions for cfbot and regular contributors, but that everyone else will use
GHA.


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

I'm not sure what path for that would exist that don't already? ISTM that'd
require downstream repos to have added their own actions workflows that
somehow interact with ours, or that they blindly run PRs from unknown folks
that add new workflows - in either case it seems they have a problem
independent of us shipping a runs-by-default actions workflow?

Greetings,

Andres Freund