It was pretty unneccary on the self-hosted runner once I added hooks to
do that, and now that there are GitHub-hosted windows-arm64 runners it's
completely useless.
Also, add TotalPhysicalMemory to 'facts'
Previously C had more space compared to D, see
https://github.com/msys2/MINGW-packages/issues/9048#issuecomment-820889210
Nowadays it's the opposite:
Name Used (GB) Free (GB) Provider Root CurrentLocation
---- --------- --------- -------- ---- ---------------
A FileSystem A:\
C 119.26 30.25 FileSystem C:\
D 3.00 147.00 FileSystem D:\ …ys2-autobuild\msys2-autobuild
Temp 119.26 30.25 FileSystem C:\Users\runneradmin\AppData\Local…
Name : AMD EPYC 7763 64-Core Processor
So:
* Move the pagefile to D:
* Move the MSYS2 install from C:/M to D:/M
* Move the checkout from C:/_ to D:/_
* (Make it configurable for self-hosted runners)
Ideally that gives us more space for builds, and according to this
it should also be faster: https://github.com/pypa/pip/pull/13129
* The most space is on D: nowadays, so just use runner.temp that's
located there and also is cleaned up afterwards
* Instead of hardcoding paths, pass the directory to the script
so it will be sorted by priority: UCRT64 -> CLANG64 -> MINGW64 -> MINGW32 -> CLANG32.
this changes the default job shown in "checks" tab, and it's a bit annoying to switch to UCRT64 job because MINGW64 is disabled for a particular package
For cases where we pass "fetch-depth: 0" to get teh full history,
enable a treeless clone, since we only care about old commits, and
not much more.
This should speed up cloning in theory.
Like in the other steps.
The staging update makes it slower since that also updates other packages
provided by the host, and it updates packages installed by the action itself,
in case they are in staging.
- This should avoid something like #16750 to occur
- this would require pacdb to be installed but it can be run
without having it installed for "checking whether to run".
For running the actual checks, pacdb is required.
- `pkgbase` is used to find the path to PKGBUILD for a given
package.
- The db which contains the files of packages is used by default.
files db is a superset of normal db, so using that should work.
I've never found it particular helpful and usually just ignored it.
One could argue that it could be improved to do what we want, but
I personally don't want to write that in bash.
It defaults to 1.8GB, bump it a bit so we can build
flang under clang64 which otherwise hits OOM
Use C: since we have 95GB free there and only 12GB on D:
