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.
There are two main changes:
* Description and reproduction steps are merged at the top, so
users don't descripe the bug and then later on have to fill
out the steps again, possibly writing the same things twice slightly differently.
This flow feels more natural imo.
* Recomend "uname" instead of "cmd.exe /c ver", the later is tricky
because of path conversion of "/c", and uname has the same info basically.
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:
Not an issue on fresh hosted runners, but on a re-used self-hosted
runner ntldd may already be installed. It's only mildly annoying having
it reinstalled every run, but easy enough to fix.
In case something crashes in CI this will show us some
information on which program crashed and why.
We register procdump as a JIT debugger which dumps the process
memory into a new file if triggered. To enable the JIT debugger
in the context of cygwin we need to set MSYS=winjitdebug.
The resulting dump file can for example be analyzed with
minidump-stackwalk or minidump_stackwalk
This will allow me to label runners according to whether I want them to
run autobuild or CI jobs (or both, theoretically).
See also msys2/msys2-autobuild#56
