If the pull request is not found or is not open, it should not be
treated as a critical error. This situation can occur after a merge.
There is no reliable way to query a pull request from a workflow_run
event, so this has been made a non-error log.
Mostly. It is annoying if we want to add some flag/option to all the cis
and then have to do it manually. Things easily get missed that way.
Skipped powershell because of course I'm not going to deal with that.
Homebrew does support 3 latest macOS versions, so while macOS 12 still
works it takes 1h 40m 7s to build. It is bit too much...
While we drop macOS 12, add macOS 15 as it is available now.
Enabled the ruff python linter in CI, and resolved the issues that were
detected by it. Ruff was used due to it's faster checking compared with
other linters like pylint. This was added to resolve the python linting
request in #13608.
It's being dropped upstream* and recently lua51 was removed along with
luajit*. mingw32 already covers 32-bit support, and it's not like we're
in dire need of this so just remove it.
*: 89521b9f8d
*: 947a8592ca
After libass update our jobs started failing. It has been fixed upstream
already, but we need to wait for next stable release to have that.
See: 6e83137cdb
This effectively bumps minimal MinGW-w64 requirement to v11.0.1. As it
is available in the latest Ubuntu LTS.
While at it clean installed packages list.
The 32-bit builds were disabled, because some packages started
disappearing. MSYS2 is slowly phasing out 32-bit support, but since we
still support it we have to test it somehow. Recent brakage with calling
convention mismatch would be spotted a lot quicker. So enable it, but
with some, not available, packages disabled.
This reverts a56d5c7fa1f20d917a179be894580a4c66c374dc
Ubuntu 24.04 linux-azure kernel, used on GHA, is compiled with
CONFIG_COMPAT_32BIT_TIME=n. This prevents running any 32-bit binaries
through wine, so disable tests when doing i686 build. 32-bit builds are
still tested on Windows.
See: https://github.com/actions/runner-images/issues/9977
It is not actively maintained, third-party, javascript wrapper for GitHub
API. The v7 version has issues and most importantly, we don't need a
JavaScript interface to create a comment. Use the first-party CLI tool
and jq.
Sort artifacts by name while at it.
I've simplified this too much during refactoring, forgot about this. We
need to preserve the latest cache with each prefix.
Fixes: c6b950ae1e722dbe8c2414017a3c521f8c5730e9
GitHub cache action doesn't allow updating cache with the same key. We
workaround this by saving the cache with a unique key each time (added
timestamp). This works fine, but since there is a limit on cumulative
storage size for all caches, it can force the master branch cache to be
evicted if a lot of PRs are updated. Cache is evicted with LRU policy,
so as long as master branch cache is used it should stay alive, but it
can happen that only PR specifc caches were only used. As a reminder,
PRs can access the master cache, but they are isolated from each other.
Because of this, it is important to keep the master cache, which is
available to all, alive longer.
The solution is to remove all old caches per branch. This is done in a
separate workflow that validates all cache items and removes ones that
would never be used anyway. If PR is closed all caches per branch are
removed. In other cases most recently used one is preserved.
It is done in a separate workflow to limit cache manipulation access.
GitHub workflows triggered by pull_request event are run in the context
of the fork and does not have access to our token, which is good thing.
Also it is quite awkward to get PR number which triggered build
workflow, so just do a full cleanup pass.
