Horton
Menu

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

Jacob Champion <jacob.champion@enterprisedb.com>

View thread
From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Andres Freund <andres@anarazel.de>
Cc: Peter Eisentraut <peter@eisentraut.org>, Nazir Bilal Yavuz <byavuz81@gmail.com>, Jelte Fennema-Nio <postgres@jeltef.nl>, Thomas Munro <thomas.munro@gmail.com>, pgsql-hackers@postgresql.org, Zsolt Parragi <zsolt.parragi@percona.com>
Date: 2026-06-03T18:12:43Z
Lists: pgsql-hackers 
On Tue, Jun 2, 2026 at 11:43 AM Andres Freund <andres@anarazel.de> wrote:
> On 2026-06-02 20:08:17 +0200, Peter Eisentraut wrote:
> > +  # FIXME: Should we also run on PRs?
> >
> > I don't know why we would, since we don't use them.
>
> From what I can tell the workflow of plenty folks during their own development
> is to open PRs in their own repo.  I don't really see a downside to also
> running on PRs, so I'm inclined to do so. Won't hurt us...

I guess I'll pipe up again to mention that we have a lot of downstream
forks. Are we certain that GitHub isn't going to opt them all into
test-every-stable-commit-and-PR on their next sync?

(There was no reply to my previous email on this, so I can't tell if
I'm just way off base. A GitHub discussion on this [1] shows
considerable confusion on how the opt-in occurs; whether it occurs for
all forks, or just new forks after we introduce the workflow; and
whether or not that protection for new forks is itself buggy.)

Thanks,
--Jacob

[1] https://github.com/orgs/community/discussions/26704

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. ci: Add GitHub Actions based CI

  2. ci: Remove support for cirrus-ci based CI