add EESSI version 2025.06 to CI workflows #40
Conversation
|
The accelerator detection is still failing, as we don't have those directories yet (we only have EESSI + EB for the CPU targets). The hooks CI is failing due to #39 not being merged yet (but it is deployed already). |
| @@ -33,7 +34,7 @@ jobs: | |||
| for shell in $(ls init/lmod); do | |||
| sed -i "s/__EESSI_VERSION_DEFAULT__/${{matrix.EESSI_VERSION}}/g" init/lmod/${shell} | |||
| done | |||
|
|
|||
There was a problem hiding this comment.
I see that .github/workflows/scripts/test_init_scripts.sh is currently version specific (causing this CI to fail)
There was a problem hiding this comment.
Apart from this, the rest of the CI is set up so that it will only pass once the accelerator directories actually exist. To get it it to pass we could manually create the structure?
There was a problem hiding this comment.
Or we build a relevant CUDA first and then fix the CI
There was a problem hiding this comment.
We can easily remove that hardcoded EESSI_VERSION in .github/workflows/scripts/test_init_scripts.sh. However, it's also loading a particular module (https://github.com/EESSI/software-layer-scripts/blob/main/.github/workflows/scripts/test_init_scripts.sh#L34), how do we deal with that?
There was a problem hiding this comment.
We can have it load EasyBuild/5.1.1 and use eb --version instead, that specific version appears in both.
You could also use an environment variable that might be EESSI version specific and use that, I did that in https://github.com/EESSI/software-layer-scripts/blob/main/.github/workflows/scripts/verify_eessi_environment.py#L49 (via https://github.com/EESSI/software-layer-scripts/blob/main/.github/workflows/tests_eessi_module.yml#L196)
No description provided.