| From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
| Subject: | Re: Heads Up: cirrus-ci is shutting down June 1st |
| Date: | 2026-06-03 23:03:20 |
| Message-ID: | CAOYmi+nOE6Ecu=G6Z18xssi-x-WDCAg2xG+D56Kyb1uTw8V7Uw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jun 3, 2026 at 12:57 PM Andres Freund <andres(at)anarazel(dot)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.
> > 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?
> than
> some folks having to figure out how to disable the workflow.
A vanishingly small percentage of our 5,700 forks have to sync up with
us in order to permanently outnumber the people who will ever test PRs
on purpose, I think.
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.
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2026-06-03 23:36:29 | Re: Heads Up: cirrus-ci is shutting down June 1st |
| Previous Message | Andrew Dunstan | 2026-06-03 23:02:11 | Re: Allow table AMs to define their own reloptions |