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

From: Andres Freund <andres(at)anarazel(dot)de>
To: 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>, Peter Eisentraut <peter(at)eisentraut(dot)org>
Subject: Re: Heads Up: cirrus-ci is shutting down June 1st
Date: 2026-06-10 23:26:26
Message-ID: m75lrfnfv5eu4xyjrordctvrrcs2wukchuweuxr72lmoy6ebcz@ddd3b2ibve5s
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2026-05-28 13:50:26 -0700, Jacob Champion wrote:
> > v3 is attached.
>
> > + uses: msys2/setup-msys2(at)v2
>
> Should we pin this? It's the only third-party action we reference, and
> Scorecard [1] complains. (I'm not convinced its other complaints in
> this category are something we want to worry about, but this caught my
> eye.)

Isn't that a rather bogus complaint? After all, pacman is then used to install
a lot of stuff that's under control of the msys2/ org. And the github images
*also* install msys2 releases that are under control of the msys2/ org. So
what increase in safety are we gaining by implementing this ourselves?

The reason I'm looking at it is that I was experimenting with using larger
runners for cfbot. Unfortunately they don't have a d:/ drive. Thus the mingw
task fails (there's also a sockdir issue, but that's trivial to fix).

I started to fix this by just installing msys ourselves [1], which also turns
out to be faster than moving the install, but then I considered that to be
somewhat too wheel-reinvent-y, compared to ust using msys2/setup-msys2.

Which lead me back here.

It turns out that using msys2/setup-msys2 might be tad slower than what I open
coded (i.e. copy-pasted from what we had for the image generation [3]). But it
does avoid downloading the packages over and over.

The only real alternative I see is to occasionally generate a downloadable
install in pg-vm-images. That'd probably be faster.

Greetings,

Andres Freund

[1] https://github.com/anarazel/postgres/actions/runs/27311452310/job/80682380845
[2] https://github.com/anarazel/postgres/actions/runs/27312189287/job/80685351695
[3] https://github.com/anarazel/pg-vm-images/blob/main/scripts/windows_install_mingw64.ps1

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2026-06-10 23:42:22 Re: Heads Up: cirrus-ci is shutting down June 1st
Previous Message Zsolt Parragi 2026-06-10 22:33:47 Re: Discard ORDER BY/DISTINCT when an ANY/IN sublink is pulled up to a join