Hi, On 2026-06-03 16:03:20 -0700, Jacob Champion wrote: > On Wed, Jun 3, 2026 at 12:57 PM Andres Freund <[email protected]> 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
