These workflows don't use any secrets other than GITHUB_TOKEN, which
only has the 'contents: read' permission. That is, if an action was
compromised, it shouldn't be able to modify the repository or steal any
secrets. I recognize that a compromised action isn't completely harmless
still. For example, the runners on GitHub have Internet access which the
action could abuse until the workflow timeout (currently 10 or 20 minutes)
expires.
Now we always use the most recent actions instead of ones that are
sometimes several months old. The hassle of updating the pinned
commit IDs goes away. The benefits feel bigger than the risks.
Link: https://github.com/tukaani-project/xz/pull/227
Sometimes the VM workflows (like FreeBSD VM on Ubuntu) get stuck
and the default timeout is six hours. While at it, set a sensible
timeout for all workflows.
Re-enable CLANG64 environment. Add CLANGARM64. Don't add MINGW64
to slightly reduce the number of runner VMs needed.
Install the required packages using the setup-msys2 action instead
of running the commands separately.
Test Autotools and CMake in the same job to reduce the number of VMs.
This doesn't slow it down too much because the msys2-setup step is
needed by both. However, do only the full builds on ARM64 because
those runners seem to be slower.
Test fewer build configurations. The point of testing on MSYS2 is to
catch Windows-related issues. It should be enough that the more unusual
build configurations are tested in ci.yml.
Run the build commands directly instead of using ci_build.bash. This
makes it easier to see what commands are run even if it is a little
more verbose now.
Run the workflow automatically when commit are pushed to master.
With the fewer build variants it's not too slow.
