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
