This patch fixes the LLVM project tests workflow on Linux. Two changes
were needed. Firstly, some commands need to be performed with sudo now
that the container executes as a non-root user. Second, we needed to
change from `ubuntu-latest` to `ubuntu-22.04` as `ubuntu-latest` not
defaults to `ubuntu-24.04` which causes `setup-python` to install a
python executable linked against a newer version of glibc that is not
found on ubuntu 22.04, which causes failures when CMake cannot execute
the python interpreter that it finds.
Previously, #77219 added a `python_version` parameter for the Github
Actions CI Ninja-based build tests. This is necessary to run component
tests on different Python versions, as is currently done by the only
user of this parameter, the [Libclang Python bindings
test](https://github.com/llvm/llvm-project/blob/main/.github/workflows/libclang-python-tests.yml).
The parameter is missing from the concurrency group of the
workflow, meaning that starting the workflow with two different Python
versions immediately cancels one of them, as pointed out by
https://github.com/llvm/llvm-project/pull/77219#issuecomment-1937105822.
This change fixes that problem by making the Python version part of the
concurrency group key, and removes the superfluous concurrency group
from the calling workflow.
The libclang python binding test CI job currently doesn't have any
restrictions on what branches it will run on when something is pushed
and also isn't restricted to the monorepo. This patch adds a branch
restriction for the push event, only running the CI job when something
is pushed to the main branch (and the path filter is met), and also adds
a filter to ensure that the job comes from a PR against the monorepo or
a push to a branch in the monorepo.
This enables the libclang python binding test to check
the oldest version of Python supported in addition
to the normal python version.
It is important to check this for issue #76664, since
many new mainstream python type annotation features
and best practices are not compatible with older
versions of python.
Additionally, frustration around ever increasing
platform dependencies and versions has been raised.
This will help ensure that python maintains reasonable
backwards compatibility.
Adding this additional build step will increase the
run time, but this should always be minimal, since
the additional libclang compilation should see 100%
cache hit rate.
Issue #76664.
Fixes#76601.
This is important to aid development of Python type annotations in the
libclang binding.
See https://github.com/llvm/llvm-project/issues/76664 for more details.
* Run on all pull requests and direct pushes.
* This makes use of the existing llvm-project-tests.yml recipe, which
will preload ccache from previous runs.
* Building libclang currently takes about 9mins when ccache is warm and
about an 1hr 20mins if it is cold using the standard GitHub ubuntu
runner.
* In the future, this could be broken into the following discrete steps
for clarity:
1. Build libclang dependency.
ninja -C build libclang
2. Run Python unit tests.
ninja -C build check-clang-python
* Followup changes will bring testing on older python versions and
static type checking.
Issue https://github.com/llvm/llvm-project/issues/76601.
