This allows for removing llvm-project-tests.yml. This significantly
reduces the complexity of this workflow (including the complexity of
llvm-project-tests.yml) at the cost of a little bit of duplication with
the other workflows that were also using llvm-project-tests.yml.
Reviewers: tstellar, DeinAlptraum
Reviewed By: DeinAlptraum
Pull Request: https://github.com/llvm/llvm-project/pull/153876
As discussed in PR #142353, the current testsuite of the `clang` Python
bindings has several issues:
- It `libclang.so` cannot be loaded into `python` to run the testsuite,
the whole `ninja check-all` aborts.
- The result of running the testsuite isn't report like the `lit`-based
tests, rendering them almost invisible.
- The testsuite is disabled in a non-obvious way (`RUN_PYTHON_TESTS`) in
`tests/CMakeLists.txt`, which again doesn't show up in the test results.
All these issues can be avoided by integrating the Python bindings tests
with `lit`, which is what this patch does:
- The actual test lives in `clang/test/bindings/python/bindings.sh` and
is run by `lit`.
- The current `clang/bindings/python/tests` directory (minus the
now-subperfluous `CMakeLists.txt`) is moved into the same directory.
- The check if `libclang` is loadable (originally from PR #142353) is
now handled via a new `lit` feature, `libclang-loadable`.
- The various ways to disable the tests have been turned into `XFAIL`s
as appropriate. This isn't complete and not completely tested yet.
Tested on `sparc-sun-solaris2.11`, `sparcv9-sun-solaris2.11`,
`i386-pc-solaris2.11`, `amd64-pc-solaris2.11`, `i686-pc-linux-gnu`, and
`x86_64-pc-linux-gnu`.
Co-authored-by: Rainer Orth <ro@gcc.gnu.org>
As discussed in PR #142353, the current testsuite of the `clang` Python
bindings has several issues:
- It `libclang.so` cannot be loaded into `python` to run the testsuite,
the whole `ninja check-all` aborts.
- The result of running the testsuite isn't report like the `lit`-based
tests, rendering them almost invisible.
- The testsuite is disabled in a non-obvious way (`RUN_PYTHON_TESTS`) in
`tests/CMakeLists.txt`, which again doesn't show up in the test results.
All these issues can be avoided by integrating the Python bindings tests
with `lit`, which is what this patch does:
- The actual test lives in `clang/test/bindings/python/bindings.sh` and
is run by `lit`.
- The current `clang/bindings/python/tests` directory (minus the
now-subperfluous `CMakeLists.txt`) is moved into the same directory.
- The check if `libclang` is loadable (originally from PR #142353) is
now handled via a new `lit` feature, `libclang-loadable`.
- The various ways to disable the tests have been turned into `XFAIL`s
as appropriate. This isn't complete and not completely tested yet.
Tested on `sparc-sun-solaris2.11`, `sparcv9-sun-solaris2.11`,
`i386-pc-solaris2.11`, `amd64-pc-solaris2.11`, `i686-pc-linux-gnu`, and
`x86_64-pc-linux-gnu`.
Co-authored-by: Rainer Orth <ro@gcc.gnu.org>
As discussed in PR #142353, the current testsuite of the `clang` Python
bindings has several issues:
- It `libclang.so` cannot be loaded into `python` to run the testsuite,
the whole `ninja check-all` aborts.
- The result of running the testsuite isn't report like the `lit`-based
tests, rendering them almost invisible.
- The testsuite is disabled in a non-obvious way (`RUN_PYTHON_TESTS`) in
`tests/CMakeLists.txt`, which again doesn't show up in the test results.
All these issues can be avoided by integrating the Python bindings tests
with `lit`, which is what this patch does:
- The actual test lives in `clang/test/bindings/python/bindings.sh` and
is run by `lit`.
- The current `clang/bindings/python/tests` directory (minus the
now-subperfluous `CMakeLists.txt`) is moved into the same directory.
- The check if `libclang` is loadable (originally from PR #142353) is
now handled via a new `lit` feature, `libclang-loadable`.
- The various ways to disable the tests have been turned into `XFAIL`s
as appropriate. This isn't complete and not completely tested yet.
Tested on `sparc-sun-solaris2.11`, `sparcv9-sun-solaris2.11`,
`i386-pc-solaris2.11`, `amd64-pc-solaris2.11`, `i686-pc-linux-gnu`, and
`x86_64-pc-linux-gnu`.
Co-authored-by: Rainer Orth <ro@gcc.gnu.org>
As discussed in PR #142353, the current testsuite of the `clang` Python
bindings has several issues:
- If `libclang.so` cannot be loaded into `python` to run the testsuite,
the whole `ninja check-all` aborts.
- The result of running the testsuite isn't report like the `lit`-based
tests, rendering them almost invisible.
- The testsuite is disabled in a non-obvious way (`RUN_PYTHON_TESTS`) in
`tests/CMakeLists.txt`, which again doesn't show up in the test results.
All these issues can be avoided by integrating the Python bindings tests
with `lit`, which is what this patch does:
- The actual test lives in `clang/test/bindings/python/bindings.sh` and
is run by `lit`.
- The current `clang/bindings/python/tests` directory (minus the
now-superfluous `CMakeLists.txt`) is moved into the same directory.
- The check if `libclang` is loadable (originally from PR #142353) is
now handled via a new `lit` feature, `libclang-loadable`.
- The various ways to disable the tests have been turned into `XFAIL`s
as appropriate.
- AArch64 doesn't `FAIL` any longer, so no `XFAIL` is necessary.
- It keeps the `check-clang-python` target for use by the Clang Python
CI.
Tested on `sparc-sun-solaris2.11`, `sparcv9-sun-solaris2.11`,
`i386-pc-solaris2.11`, `amd64-pc-solaris2.11`, `i686-pc-linux-gnu`, and
`x86_64-pc-linux-gnu`.
This patch bumps workflows depending upon the Linux CI container to
ubuntu 24.04. The 22.04 container is no longer being built as it was
recently bumped to 24.04, so this patch moves all of these workflows
over to the new container to keep them updated and ensure they are using
an actually maintained version of the container image.
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.
