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

On 04.06.26 04:46, Andres Freund wrote:
> Hi,
> 
> On 2026-06-03 19:36:29 -0400, Andres Freund wrote:
>>> 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).
> 
> 
> Attached is a possible implementation of this.  If the PG_CI_ENABLED
> repository variable is not set to 1, we run as little CI as possible.
> 
> To make that less confusing, emit a summary whenever we skip running CI, with
> a message explaining how to enable CI.  See e.g. the bottom of
> https://github.com/anarazel/postgres/actions/runs/26926523027

I think this would be a great solution.  The message is easy to find and 
the instructions are easy to follow.

I suggest maybe using "Note" instead of "Caution" because otherwise it 
sounds quite dangerous and maybe we want to reserve that for when we 
have some serious things to report.  Also I suggest writing "PostgreSQL 
CI is disabled ...", not just "CI is disabled ...", since that might 
otherwise be confusing, especially since this is being considered in the 
context of downstream forks that were not expecting this.  (I also 
considered "PostgreSQL community CI ..." to be even more explicit.)

> Attached is a squashed version of my earlier changes. In addition:
> 
> - src/tools/ci/README was updated with the knowledge that the workflow
>    may or may not be enabled in a fork
> 
> - a few typos etc were fixed
> 
> - the change above was added as a third patch

Since you made a point of reordering dependencies, the 
${MINGW_PACKAGE_PREFIX}-zstd is not quite in the right place.

> I'm on the fence whether we want the third change or not.

This seems useful.  Otherwise, if you have a private fork and just want 
to park some patches, this will blow through your private repository 
free credits in about 5 or 6 builds.  (Learned that a few days ago. ;-) )