[Github] Explicitly requesting Ubuntu 22.04 for SPIRV test

[adam-yang]

For the same reason as #122221, this fixes build failure from missing python3.

[llvmbot]

@llvm/pr-subscribers-github-workflow

Author: Adam Yang (adam-yang)

Changes

For the same reason as #122221, this fixes build failure from missing python3.

---

Full diff: https://github.com/llvm/llvm-project/pull/122395.diff

1 Files Affected:

• (modified) .github/workflows/spirv-tests.yml (+1-1)

diff --git a/.github/workflows/spirv-tests.yml b/.github/workflows/spirv-tests.yml
index 75918e73e89737..34c77a398c1504 100644
--- a/.github/workflows/spirv-tests.yml
+++ b/.github/workflows/spirv-tests.yml
@@ -26,4 +26,4 @@ jobs:
       build_target: check-llvm-codegen-spirv
       projects:
       extra_cmake_args: '-DLLVM_TARGETS_TO_BUILD="" -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD="SPIRV" -DLLVM_INCLUDE_SPIRV_TOOLS_TESTS=ON'
-      os_list: '["ubuntu-latest"]'
+      os_list: '["ubuntu-22.04"]'

[farzonl]

Alternatively, why not just install python3 explicitly?

[boomanaiden154]

Alternatively, why not just install python3 explicitly?

We would just get the system default installation of Python (which already exists), which precludes us from testing with different python versions.

[farzonl]

We would just get the system default installation of Python (which already exists), which precludes us from testing with different python versions.

I apologize if this is a dumb question, but If we need multiple python versions, why aren't we using pyenv to toggle between versions?

[llvm-beanz]

The system default version of Python on Ubuntu 22.04 is Python 3.10. Some of our actions require 3.11 or 3.12 which we use the setup-python action to configure.

IIUC, the issue isn't really about the version of python, it is about the setup-python action doing something dumb and installing a binary for python built for Ubuntu 22.04 instead of matching the runner configuration. So if we run this on ubuntu-latest we get a python binary linked against glibc from Ubuntu 22.04 instead of matching ubuntu-latest (24.04).

@boomanaiden154 has done the actual debugging on this, so he can correct me if I'm misunderstanding the situation.

[boomanaiden154]

I apologize if this is a dumb question, but If we need multiple python versions, why aren't we using pyenv to toggle between versions?

It is a lot nicer to use setup-python when it works. It makes it easier to adjust things in the workflows and I would say removes some complexity given setup-python is pretty standard in GHA workflows whereas I have never seen (in my somewhat limited experience) pyenv used in a CI workflow.

so he can correct me if I'm misunderstanding the situation.

The versions are backwards in your explanation, but otherwise that's exactly right. setup-python looks at the runner image rather than what is in the container to determine what it should install. Since we were using ubuntu-latest as the runner image and that changed a couple weeks ago to ubuntu-24.04, setup-python was installing a python binary for 24.04 (and its glibc) whereas the container image that it was installing everything into was ubuntu 22.04.

On top of fixing the issue, pinning the versions is reasonably good practice so things don't get rolled underneath us and break us like what happened here.

[adam-yang]

Looks like there's a real problem with some spirv tests, maybe spirv-tools versions changed or something and is rejecting some SPIRV that was passing validation before.

[boomanaiden154]

Looks like there's a real problem with some spirv tests, maybe spirv-tools versions changed or something and is rejecting some SPIRV that was passing validation before.

Is it failing at tip of tree too? If they are, it's probably good to land this patch and then fix forward the new failures. If I had to guess I would say the failures also exist at ToT, but there are always weird edge cases when trying to make CI work.

[adam-yang]

Looks like there's a real problem with some spirv tests, maybe spirv-tools versions changed or something and is rejecting some SPIRV that was passing validation before.

Is it failing at tip of tree too? If they are, it's probably good to land this patch and then fix forward the new failures. If I had to guess I would say the failures also exist at ToT, but there are always weird edge cases when trying to make CI work.

Yes it repros on tip of tree too. I'm pretty sure latest changes in SPIRV-Tools just broke these tests because the errors don't repro when I use an older release tag of SPIRV-Tools. I haven't pinpointed which commit broke it yet.

I'll just check this change in and resolve the SPIRV-Tools issue separately.