| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
| Cc: | 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-04 13:27:42 |
| Message-ID: | d6231d99-22ec-4aad-9e99-24db4182fd67@eisentraut.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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. ;-) )
| Attachment | Content-Type | Size |
|---|---|---|
| v10.1.pe-0001-Use-NOTE-instead-of-CAUTION.patch | text/plain | 1.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2026-06-04 13:28:46 | Re: Heads Up: cirrus-ci is shutting down June 1st |
| Previous Message | Ewan Young | 2026-06-04 12:44:19 | Re: (SQL/PGQ) cache lookup failed for label |