Hi,
On 2026-05-28 13:50:26 -0700, Jacob Champion wrote:
> > v3 is attached.
>
> > + uses: msys2/setup-msys2@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
