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

Hi,

On 2026-06-04 14:12:32 +0300, Nazir Bilal Yavuz wrote:
> 0001 LGTM. I really liked the slicing solution on Windows VS.

Cool.

> 0002:
>
> Nitpick: There are two mentions of GitHub Actions with lowercase in
> the 'ci_macports_packages.sh', perhaps we can update them with 'GitHub
> Actions'.

done.

> 0003:
>
> I think it makes sense to be explicit about this. I don't think this
> CI will cause any problems (to users) since Github Actions is free on
> public repositories but it is better safe than sorry.

It turns out that if you make a private fork of the public PG repo, it's
rather easy to churn through the free minutes included in the account...

But I think Jacob's concern is more that there's thousands of forks of
postgres, if they all suddenly start to run CI, that's quite a bit of wasted
effort (including downloading our containers etc).

> Also, from discussion on PostgreSQL Hacking Discord channel:
>
> Thomas Munro mentioned:
>
> > Maybe "Report if CI is not enabled in this repository" would be
> slightly clearer. it's not really a warning, it's just stating a
> fact. or maybe "Report if PG_CI_ENABLED is not set to 1 in this
> repository" even?

For a moment I thought we could solve this by using ${{case(...)} in the job's
.name, but it turns out those are only evaluated when the job gets closer
would have a chance to run. So it ends up looking too ugly.

> I liked 'Report if CI is not enabled in this repository'.

After Thomas' suggestion I first went with:
"Report if repo has not opted into CI"
but that turned out to be truncated in the display. So now I went with
"Report if not opted into CI"
which is not truncated.

How is that?

> Jelte Fennema-Nio mentioned:
>
> > I think being opt-in is fine. I'd actually fail the build though, instead of succeeding. People are probably more inclined to click the red cross next to a commit than a green checkmark.
>
> I think this makes sense too. Green color can be seen as it is
> expected and nothing wrong.

I don't like it much, because it means suddenly a lot of red will appear in
people that just have a fork to look at code etc...

Downthread you wrote:

On 2026-06-04 15:13:14 +0300, Nazir Bilal Yavuz wrote:
> On Thu, 4 Jun 2026 at 14:12, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com> wrote:
> >
> > >
> > > 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 it would be nice to mention that we need to create a
> 'Repository variable' not an 'Environment variable'.

Updated, both in the message and the README.

Nearby:

On 2026-06-04 15:27:42 +0200, Peter Eisentraut wrote:
> On 04.06.26 04:46, Andres Freund wrote:
> > 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.

Cool.

It's not great that it doesn't show up if one isn't logged in, but I think
it's about as good as we can do.

> 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.

I changed it to IMPORTANT, that seemed more fitting than just a NOTE?

> 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.

Done.

> (I also considered "PostgreSQL community CI ..." to be even more explicit.)

That feels a bit too much. I made it ${{github.workflow}}, which is the name
set at the top of the workflow.

I also changed to use tee -a for the printing the opt-in summary, so the
message is visible inside the step, as otherwise one doesn't see anything when
navigating to the "Report ..." job. It's just markdown printed literally, but
it seems readable enough.

I'm a bit torn about "opted into in this repository" vs "opted into for this
repository". Any language nerds ready for action?

Greetings,

Andres Freund