[Github] Allow CI to run different Python version tests at once

[DeinAlptraum]

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.
The parameter was however not added to 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 #77219 (comment). 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.

[llvmbot]

@llvm/pr-subscribers-github-workflow

Author: Jannick Kremer (DeinAlptraum)

Changes

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.
The parameter was however not added to 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 #77219 (comment). 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.

---

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

2 Files Affected:

• (modified) .github/workflows/libclang-python-tests.yml (-6)
• (modified) .github/workflows/llvm-project-tests.yml (+1-1)

diff --git a/.github/workflows/libclang-python-tests.yml b/.github/workflows/libclang-python-tests.yml
index 43ded0af3ac21c..801a701724789a 100644
--- a/.github/workflows/libclang-python-tests.yml
+++ b/.github/workflows/libclang-python-tests.yml
@@ -22,12 +22,6 @@ on:
       - '.github/workflows/libclang-python-tests.yml'
       - '.github/workflows/llvm-project-tests.yml'
 
-concurrency:
-  # Skip intermediate builds: always.
-  # Cancel intermediate builds: only if it is a pull request build.
-  group: ${{ github.workflow }}-${{ github.ref }}
-  cancel-in-progress: ${{ startsWith(github.ref, 'refs/pull/') }}
-
 jobs:
   check-clang-python:
     # Build libclang and then run the libclang Python binding's unit tests.
diff --git a/.github/workflows/llvm-project-tests.yml b/.github/workflows/llvm-project-tests.yml
index 17a54be16badc1..95a3890c0d2dc7 100644
--- a/.github/workflows/llvm-project-tests.yml
+++ b/.github/workflows/llvm-project-tests.yml
@@ -51,7 +51,7 @@ concurrency:
   # Cancel intermediate builds: only if it is a pull request build.
   # If the group name here is the same as the group name in the workflow that includes
   # this one, then the action will try to wait on itself and get stuck.
-  group: llvm-project-${{ github.workflow }}-${{ inputs.projects }}${{ github.ref }}
+  group: llvm-project-${{ github.workflow }}-${{ inputs.projects }}-${{ inputs.python_version }}${{ github.ref }}
   cancel-in-progress: ${{ startsWith(github.ref, 'refs/pull/') }}
 
 jobs:

[DeinAlptraum]

@linux4life798 might also want to take a look

[tstellar]

LGTM. Thanks for fixing this.

[boomanaiden154]

LGTM. I'm assuming you've tested this?

Thanks for fixing this. This has been on my todo list for quite a while. 😅

[DeinAlptraum]

@boomanaiden154 yup, you can see on the CI for this branch that it ran the tests for both versions, and I've tested on my fork that it still correctly cancels simultaneous runs for the same version.

Thanks for reviewing!

On another note, now that I think about it, is there any need to actually run the build twice? Shouldn't it be sufficient to build libclang once, and then just run the Python tests with separate Python versions?

[boomanaiden154]

On another note, now that I think about it, is there any need to actually run the build twice? Shouldn't it be sufficient to build libclang once, and then just run the Python tests with separate Python versions?

I'm not sure exactly how the bindings are setup. Given it interfaces with a C++ API, I'm guessing we're pulling in cpython headers somewhere (whether directly or indirectly) which means building against different platforms might produce different results/errors at build time. That would mean we need to build everything separately for different python versions.