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. ;-) )
From 143f43db2af420807bf488a0c8d334bcbe1d2ae7 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <[email protected]>
Date: Thu, 4 Jun 2026 14:51:03 +0200
Subject: [PATCH v10.1.pe] Use NOTE instead of CAUTION.
---
.github/workflows/pg-ci.yml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index eaf32c756e2..1b0e967ee7d 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -150,15 +150,15 @@ jobs:
- name: Warn
env:
MSG: |
- > [!CAUTION]
- > CI is not enabled in this repository
+ > [!NOTE]
+ > PostgreSQL CI is not enabled in this repository
>
> To enable, go to
${{github.server_url}}/${{github.repository}}/settings/variables/actions
> and create a new variable named PG_CI_ENABLED, with the value 1.
>
> To avoid seeing this message over and over, go to
>
${{github.server_url}}/${{github.repository}}/actions/workflows/pg-ci.yml
- > and click on the three dots at the top right and choose "Disable
workflow"
+ > and click on the three dots at the top right and choose "Disable
workflow".
run: |
echo "$MSG" >> "$GITHUB_STEP_SUMMARY"
--
2.54.0
